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Abstract 



The thesis describes a logical formalization of natural-language database in- 
terfacing. We assume the existence of a "natural language engine" capable 
of mediating between surface linguistic string and their representations as 
"literal" logical forms: the focus of interest will be the question of relating 
"literal" logical forms to representations in terms of primitives meaningful 
to the underlying database engine. We begin by describing the nature of the 
problem, and show how a variety of interface functionalities can be consid- 
ered as instances of a type of formal inference task which we call "Abductive 
Equivalential Translation" (AET); functionalities which can be reduced to 
this form include answering questions, responding to commands, reasoning 
about the completeness of answers, answering meta-questions of type "Do 
you know...", and generating assertions and questions. In each case, a "lin- 
guistic domain theory" (LDT) F and an input formula F are given, and the 
goal is to construct a formula with certain properties which is equivalent to 
F, given F and a set of permitted assumptions. If the LDT is of a certain 
specified type, whose formulas are either conditional equivalences or Horn- 
clauses, we show that the AET problem can be reduced to a goal-directed 
inference method. We present an abstract description of this method, and 
sketch its realization in Prolog. The relationship between AET and several 
problems previously discussed in the literature is discussed. In particular, 
we show how AET can provide a simple and elegant solution to the so-called 
"Doctor on Board" problem, and in effect allows a "relativization" of the 
Closed World Assumption. The ideas in the thesis have all been implemented 
concretely within the SRI CLARE project, using a real projects and pay- 
ments database. The LDT for the example database is described in detail, 
and examples of the types of functionality that can be achieved within the 
example domain are presented. 

KEYWORDS: Natural language processing, natural language inter- 
faces, databases, logic programming, equivalences, Closed World Assump- 
tion, "Doctor on Board" problem 
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Chapter 1 

Introduction 



1.1 What this thesis is about 

The basic aim of this thesis is to describe a logical formalization of the topic 
usually described as "Natural Language Database Interfacing" , presented in 
a way which is consistent with the methods of present-day computational 
linguistics and artificial intelligence. We will interpret the phrase "Natural 
Language Database Interfacing" in a broad sense, to encompass any kind of 
use of language in connection with a database; this is of course somewhat too 
broad as it stands, but we want to stress that we are not limiting ourselves 
to the procedural goal of constructing a system that can use the database 
to answer questions posed in natural language. Our starting point is rather 
that we are building a theory which describes the relationship between a 
database and the natural-language utterances which in some way or another 
make reference it. These utterances can certainly be questions explicitly 
about the content of the database ("Which payments were made on May 
23rd?"), but they can also be commands to supply information ("Tell me 
about payments made on May 23rd"), statements supplying new informa- 
tion for the database ("A payment to British Telecom was made on May 
23rd"), or meta-questions ("Do you know whether any payment was made 
on May 23rd?"). We will not assume either that use of language is exclu- 
sively by human participants in the dialogue: we want the theory to support 
generation of language, for example statements describing facts already in 
the database, or questions asking for fillers of incomplete database records. 
Since this thesis is within the field of computer science (rather than, for 
example, those of linguistics or philosophy), we also make another demand, 
namely that the theory should be computationally tractable: that is to say, it 
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should in principle (and, preferably, in practice), be capable of efficient real- 
ization as a functioning program. In accordance with a now well-established 
paradigm, such a program will operate in a way that can be conceptualized 
as performing inference on the theory to obtain conclusions of a particular 
type. 

The goals set out in the paragraph above are so vague that they could 
potentially encompass an almost limitless variety of approaches, (although 
it is also worth noting that they in fact exclude most previously published 
work on the subject: see section |2.2| ). We will now narrow them to focus 
more closely on the actual research that has been accomplished here. First, 
we will drastically simplify the problem by not dealing directly with natural 
language, but only with logical formulas representing natural language ut- 
terances. It is of course by no means clear that such a move is really possible 
(or, some would claim, even desirable); on the other hand, a great deal of 
work has been done during the last century on the representation of lan- 
guage in logic, which has recently found expression in the creation of natural 
language engines, large implemented systems practically capable of fairly 
robust automatic translation between utterances and their logical represen- 
tations. This thesis makes extensive, often implicit, use of one such system, 
the SRI Core Language Engine (CLE), which is described in more detail in 
section 1.2 . By availing oneself of this accumulated body of knowledge, it is 
possible to abstract away the linguistic phenomena which intuitively belong 
to the surface form of language (morphology, and much of the simpler as- 
pects of syntax), and instead concentrate on what hopefully are the deeper 
semantic issues: how words refer to database records, and how the context in 
which a word is used can affect the way in which it refers. In order for there 
still to be a problem to solve, it is necessary to limit the scope of operation 
of the language engine; we demand, roughly, that the logical representations 
which it assigns to utterances should be in some sense "literal", that is to 
say that there should exist a close correspondence between the component 
words of the utterance and the component symbols of its logical represen- 
tation. Although this principle is not applied with complete rigidity in the 
CLE, it is given sufficiently full expression that we hope the results will be 
of fairly general relevance. In the main body of the thesis, we will later see 
numerous examples of these "literal" logical forms. 

Informally, the key idea in our treatment of the subject is that of "trans- 
lation" : we wish to translate vague natural language utterances into precisely 
defined expressions in a formal language that can be used to manipulate and 
reason about the database. By replacing natural language utterances with 
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their logical forms, we can make this goal more precise: given a logical form 
F, whose constants correspond to word-senses, we might wish to find an 
equivalent expression, F', whose constants correspond to database objects 
and relations, perhaps together with elementary arithmetic operations and 
other uncontroversial relations; this, roughly, will be our characterization of 
the analysis type of task, the class of tasks where natural language has be 
turned into database commands. Conversely, given a logical expression F 
whose constants refer to the database, we might wish to find an equivalent 
expression F' whose constants are word-senses; this will be the form of gen- 
eration tasks, tasks where the database is given, and natural language is to 
be produced. 

The ideas in the last paragraph constrain the picture considerably. If we 
are to talk about logical forms of natural language utterances being "equiva- 
lent" with formulas directly representing database concepts, then the equiv- 
alence must be with respect to a background theory. Calling the theory T, 
we will be able to define a formula F^b expressed in the "database language" 
to be a translation of a logical form Fn ng iff 

r => {F ling = F db ) (i.i) 

Thus one of our major goals will be the construction of suitable theories T, 
and we will have a good deal to say about this in a moment. Before doing 
so, however, we will make an important modification to ( |1.1| ). It turns out 
in practice that if V is a fairly general theory (that is to say, if it is applicable 
in a wide range of situations), then it will often be the case that equivalences 
like those in ( |1 . 1[) can only be proved to follow from it with the addition of 
extra assumptions A; the reason why these assumptions have to be treated 
specially is that they are defeasible, that is to say that additional knowledge 
may force them to be retracted. So the modified form of our specification of 
what it means for a logical form Fu ng and a database expression Fdb to be 
equivalent is 

TUA^ (F lmg = F db ) (1.2) 

where T is a background theory and the A belong to a set of permissible 
assumptions. In this case, we will say that F^ is an abductive equivalential 
translation of Fu ng , the translation being from the logical vocabulary of 
word-senses to the logical vocabulary of database concepts. Since equivalence 
is a symmetric relation, it will be equally correct to say that Fu ng is an 
abductive equivalential translation of F d b, reversing the roles of the source 
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and target languages. The greater part of the sequel will be concerned 
with exploring the ramifications of the concept of abductive equivalential 
translation (hereafter usually shortened to AET), and how it can be used to 
provide a practically useful framework within which various natural language 
interfacing tasks can be formalized and implemented. Illustrative examples 
will be taken from the SRI CLARE system, an advanced natural language 
and reasoning system built on top of the CLE, which makes extensive use 
of AET. 



The rest of the thesis is organized as follows. Section 1.2 gives an overview 
of CLARE, focussing on the role that AET plays in the system as a whole, 
and Section 1.3 shows an example session with CLARE. The thesis proper 
starts with Chapter |2|, which explains in more detail the various interface 
functionalities that we will consider, and how they can be realized in terms 
of AET; it also discusses en route the rough form of the "background the- 
ory" r and the permissible assumptions A of (1.2). Chapter |3| then considers 
computational mechanisms that can be used to solve the problem of finding 
an abductive equivalential translation of a formula given a background the- 
ory: it is shown that this can be reduced to a goal-directed inference task if 
r is constructed in a certain way. Theories of this form will be referred to as 
equivalential linguistic domain theories, and are the subject of Chapter |j. A 
goal-directed reasoning engine used to support the translation functionalities 
of chapter || is described in chapter [|. 

Up to this point, we will mostly have considered only the functionalities 
which involve mapping queries and assertions into a form that can be used by 
the database. Chapter || shows how we can use the framework in the reverse 
direction to formalize generation of statements describing the contents of 
database records, and questions asking about the fillers of unfilled database 
fields. Finally, chapter [7| sums up and concludes. There are three appendices. 
Appendix |A] discusses and motivates the theory of question semantics used 
throughout the thesis; appendix |B| defines the syntax and semantics of TRL, 
the extended first-order logic used throughout the thesis; and appendix |C| 
outlines the methods used in CLARE to translate TRL logical expressions 
into SQL query language to connect to actual SQL databases. 



1.2 The SRI CLARE system 

In this section we will briefly describe the SRI CLARE system. CLARE is 
a sophisticated natural language and reasoning system built on top of the 
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SRI Core Language Engine (CLE). Although it would certainly have been 
impossible to carry out the research reported here without the benefit of 
an implemented environment like that provided by the CLE, much of the 
CLE's internal structure is at best of only tangential interest in this context; 
since the CLE is well-described elsewhere (Alshawi 1992), we will confine 
ourselves to providing sufficient detail that the reader will be able to see 
where the translation and reasoning components fit into the total scheme. 

CLARE is an integrated system, intended to provide the core language 
processing capabilities needed for a wide range of tasks such as knowledge- 
based access, machine translation, text scanning and speech synthesis, which 
in one way or another involve manipulating human language. The design of 
CLARE is characterized by giving high priority to modularity and declarative 
representation of information: the system is composed of a dozen or so 
cleanly separated subsystems, which pass information, coded in well-defined 
intermediate representations, over well-defined interfaces. Different types of 
linguistic knowledge are available in various declaratively specified forms; 
the processing modules will usually compile the declarative knowledge they 
need into a form suitable for the uses to which they intend to put it. 

At the coarse level of granularity which will suffice for our purposes, 
CLARE can be separated into three main pieces. The first of these is the 
CLE, which can be viewed as a module that converts between two levels of 
representation, surface form and quasi logical form (QLF). Conversion can 
take place in either direction; thus the CLE's analysis module can use the 
declaratively specified linguistic information to derive QLF representations 
from surface forms, while the generation module uses the same information, 
compiled in a different way, to derive surface forms from their QLF rep- 
resentations. QLF can be characterized as a logical representation which 
attempts to encode only the linguistic information in the utterance; this 
implies that QLF representations of vague expressions like pronouns and 
ellipsis are themselves vague (Alshawi and Crouch 1992). We will actually 
have little to say about QLF in this thesis, since it is a level of representation 
that is difficult to use directly to support inferential reasoning. 

The second major piece of CLARE is the resolution component, which 
converts between QLF and logical form representations; logical forms are 
represented in a conservatively extended first-order logic called Target Rea- 
soning Language (TRL), defined in appendix ||. The resolution component 
converts QLF into TRL by "resolving" referentially vague sub-expressions; 
this can involve operations corresponding to finding referents for pronouns 
and definite noun-phrases, expanding elliptic phrases, and determining the 
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relative scope of quantifiers. Typically, all these operations involve inference 
in some way. In the reverse direction, CLARE has a limited ability to syn- 
thesize QLFs corresponding to TRL expressions. We will say a little more 
about the resolution component (primarily in Chapter ||), but nearly the 
whole of the thesis will focus on CLARE's third main subsystem, the infer- 
ence component. This is the part that manipulates TRL expressions, and 
which mediates between TRL and the expressions used for direct communi- 
cation with the underlying database; as we have said above, the inference 
component also provides an important functionality utilised by the resolu- 
tion subsystem. In the annotated example session with CLARE shown in 
the next section, the reader will be able to see more clearly how the three 
top-level sub-systems in CLARE interact. 

1.3 An example session with CLARE 

In this section, we present an example session with CLARE to illustrate 
some of its capabilities; we will focus on the inference sub-system. Some of 
the less interesting output will be edited away. Comments will be in normal 
font, and input from the user prefixed by user». 

In the session, CLARE is acting as an interface to a database of projects 
and payments. The database records are based on real ones for SRI Cam- 
bridge, but for confidentiality reasons names have been replaced by fanciful 
variants^], and the larger sums of money randomly reduced in size. 

We omit the start-up sequence, and jump to the first sentence, a simple 
question. In this first example, we present the entire CLARE output; in 
subsequent sentences, we will mostly focus on the inference stage. 

user» List all payments made during 1990. 

Segmentation. Morphology. Phrases. Syntactic analysis. 

Semantic analysis. 

6 well-sorted semantic analyses. 

Preference ranking. 

Complete sentence with bracketing: 

"{list {all payments {made {during {1990}}}}}." 



1 Credit for the more amusing entries is due to Arnold Smith. 
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Word senses (unordered) : 

list : enumerate 
payment : paying event 

make: perform (rather than "present with") 

CLARE has analyzed the sentence as far as the QLF level of representa- 
tion, and prints it out with bracketing to indicate major constituents and 
paraphrases of the content words. It now goes on to the resolution stage. 

Initial Resolution. 

"list all payments made during 1990 (the year) ! " 

Entities: you ; 

all payments made during 1990 (the year) ; 
1990 (the year) ; 

Scoping. 

CLARE has now completed the resolution stage as well (including quantifier 
scoping) , and produced a logical form. The only non-trivial action taken has 
been to resolve "1990" to a year (rather than for example to a project whose 
project ID is 1990). The resulting LF is now passed to inference. 

Assumptions used in query translation: 

all_transactions_ref erred_to_are_f rom_SRI 

The command could be translated into an executable form, if it was per- 
missible to assume that all the payments are from SRI. The result, slightly 
simplified, is the following formula: 

forall( [Id, Amt, Payee, Date] 

impl (sql_select ( [Id, Amt , Payee , Date] 

[SELECT DISTINCT t_l.trn_id, 
t_l . amount , 
t_l .payee, 
t_l . cheque_date , 

FROM TRANS t_l, 

WHERE t_l. amount > '0', 
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AND 'l-JAN-90' <= t_l . cheque_date, 
AND t_l . cheque_date <= '31-DEC-90'] ) , 
execut e_in_f uture (display ( [Id , Date , Payee , Amt] ) ) ) ) 

This states that the command will be executed if at some point in the future 
each tuple describing an appropriate payment is displayed. 

In order to perform the translation, CLARE has made use of a number 
of facts about the relationship between language and database, which are 
stored as logical axioms in its linguistic domain theory for the projects and 
payments domain. 

1. Axioms determining the relationship between the word payment and 
the records in the TRANS relationship; these say, roughly, that payments 
made by SRI between August 17th, 1989 and March 31st, 1991 stand 
in a one-to-one relationship with records in the TRANS relationship for 
which the amount field is positive. 

2. Axioms defining the meaning of the verb make in the case when its 
object is a payment: these say in effect that a payment, and the making 
of a payment, are one and the same thing. 

3. Axioms defining how the word during is used; roughly, that an event 
is "during" an interval if the time-point associated with it follows the 
time-point associated with the start of the interval, and precedes the 
one associated with its end. 

4. An axiom relating the time-point associated with a payment to the 
cheque_date field in the TRANS record corresponding to the payment. 

5. Axioms defining an appropriate interpretation of the verb show when 
applied to a payment: roughly, that "showing" a payment is the same 
as finding the payment's associated TRANS record, and printing a tuple 
consisting of its trn_id, cheque_date, payee and amount fields. 

CLARE executes the command, resulting in a number of tuples being printed: 

Executing command: 

Answer : 

[100321 ,09-JAN-90, Martian Systems pic, 780] 
[100322 , 09- JAN-90 , UKU , 150] 
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[100323, 09- JAN-90,PonyRides International Ltd, 24] 
[100324, 09- JAN-90,PonyRides International Ltd, 36] 
[100325, 09- JAN-90,B Baggins and Sons Ltd, 79. 09] 

[100755 , 17-DEC-90 , Maxwells , 492 . 57] 
[100756 , 17-DEC-90 , Maxwells , 270 . 96] 
[100758 , 21-DEC-90 , Point Counterpoint ,6.8] 
[100849 , 29-N0V-90 , Ziek Fender , 4788 . 73] 
[100850 , 29-NDV-90 , Reg Donaldson , 2853 . 84] 

Finally, a "key" is displayed: CLARE uses its knowledge about the relation- 
ships between words and database fields to find one or more common nouns 
to describe each field in the tuples it has printed. 

Key for answer fields: 

[A,B,C,D] 

A: payment, transaction 
B: date, time 
C: payee 

D : amount , money 
Command executed. 

user>> Show payments from 12/90 to 2/91. 



"show all payments from 12/1990 (the month) to 
2/1991 (the month) ! " 

We skip the initial parts of processing, except for the paraphrase summary 
produced by the resolution stage: this confirms that CLARE has correctly 
interpreted 12/90 and 2/91 as months. 

Assumptions used in query translation: 

all_transactions_ref erred_to_are_f rom_SRI 
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Once again, CLARE has had to assume in order to carry out the translation 
that the payments referred to are ones made by SRI. In addition to the facts 
from its linguistic domain theory used in translating the previous sentence, 
it has had to apply knowledge concerning the use of the prepositions to and 
from: specifically, it has used axioms which state that these prepositions 
refer to relations of temporal precedence when used together with arguments 
that can be interpreted as time points or intervals. Further axioms state that 
months are objects of such a type. The final translated formula is similar to 
the previous one. 

Executing command: 



Answer : 



[100721, 04-DEC-90, Mohawk Taxi Services , 172 . 55] 
[100722 ,04-DEC-90, Maybe' s Couriers Inc,27] 
[100723 , 04-DEC-90 , World Travel , 253 . 35] 
[100724 , 04-DEC-90 , World Travel , 226] 
[100725 , 04-DEC-90 , World Travel , 226] 

[100846 , 21-FEB-91 , Streetside Newsagent , 12 . 22] 
[100847, 21-FEB-91, Mohawk Taxi Services , 151 . 7] 
[100851 , 01-FEB-91 ,Reg Donaldson, 1759 . 13] 
[100853 , 27-FEB-91 , Zippy Express , 153 . 74] 
[100854 , 28-FEB-91 , Camreality , 45 . 2] 

Key for answer fields: 

Command executed. 

The next question involves translating into a form that involves a counting 
operation: we suppress most of the details. 

user» How many payments were made during 1990? 

"how many payments were made during 1990 (the year)?" 
Assumptions used in query translation: 



all_transactions_ref erred_to_are_f rom_SRI 
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Using axioms already described, the final result of translation is as follows: 

foralK [Count] , 

impl (sql_select ( [Count] , 

[SELECT COUNT ( DISTINCT t_l.trn_id ), 
FROM TRANS t_l, 

WHERE t_l.cheque_date <= '31-DEC-90', 
AND 'l-JAN-90' <= t_l.cheque_date, 
AND t_l. amount > '0']), 
execute_in_f uture (display ( [Count] )))) 

and the result of executing it is 

Answer : 

426 

Key for answer fields: 
A 

A : number 

The next example, though superficially very similar, reveals a couple of novel 
points. 

user>> How much did Cow's Milk receive from SRI? 

"how much money did Cow's Milk Dairies (the payee) 
receive from SRI (the payee)?" 

Assumptions used in query translation: 

money_is_measured_in_pounds_sterling 

transact ions_referred_to_made_between_1989/8/17_and_1991/4/l 

In this question, the payee is explicitly specified as SRI, but the range of 
payment dates is not mentioned. CLARE consequently no longer needs to 
print a warning that the payee is assumed to be SRI, but instead warns the 
user about the range for which payment records exist. The final result of 
translation is 



12 



CHAPTER 1. INTRODUCTION 



foralK [Total] , 

impl (sql_select ( [Total] , 

[SELECT SUM ( DISTINCT t_l. amount ), 
FROM TRANS t_l, 

WHERE t_l. payee = 'Cow"s Milk Dairies', 
AND t_l .amount > '0' , 
AND t_l.cheque_date < ' 15-JUL-93'] ) , 
execute_in_f uture (display ( [Total] ) ) ) ) 

which when executed yields the answer 

Executing command: 

Answer : 

454.22 
Key for answer fields: 
A 

A: quantity 
Command executed. 

(Warning: the response is based on possibly incomplete 
information) . 

CLARE has been told that it is allowed to assume that the payments referred 
to have all been made during the period for which payment records exist. 
The assumption has however also been flagged as one which can potentially 
result in incomplete answers, so the warning on the last line is issued. 
In the next example, this theme is carried a stage further. 

user» Which companies received cheques from SRI last 
February? 

"which companies received some cheques from SRI 
(the payee) during 2/1992 (the month)?" 
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The command could not be translated without violating 
the following: 

transact ions_referred_to_made_between_1989/8/17_and_1991/4/l 

CLARE was able to complete translation of the LF into executable form 
with the usual assumption that all the transactions referred to were made 
in the period for which records exist. This time, however, it is able to prove 
that the assumption is contradicted by the context in which it is made, since 
February 1992 is after March 1991. It consequently informs the user of this 
and does not attempt to execute the translated query. 

The next few examples illustrate CLARE's handling of the well-known 
"Doctor on Board" problem, which arises when database fields are filled by 
Boolean (yes/no) values. 

user» Which employees have a car? 

(resolution does nothing interesting) 

Assumptions used in query translation: 

all_cars_ref erred_to_are_company_cars 
all_employees_ref erred_to_are_at_SRI 

CLARE needs to access a new set of axioms in order to translate this query: 

1 . Axioms defining the usage of the expression "SRI employee" : roughly, 
that objects which can be referred to as "SRI employees" stand in 
one-to-one correspondence with records in the EMPLOYEE relation. 

2. Axioms defining the usage of the words "have" and "company car" 
when applied to SRI employees: roughly, that there is an object which 
can be referred to as a "company car" , and which a given SRI employee 
can be referred to as "having" if and only if the has_car field in the 
corresponding EMPLOYEE record is filled by a y. 

3. "Employee" may be assumed to be equivalent to "SRI employee", and 
"car" to "company car" . 

Using these facts, CLARE is able to translate the query into the executable 
form 
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f orall ( [Empl] , 

impl (sql_select ( [Empl] , 

[SELECT DISTINCT t_l.name, 
FROM EMPLOYEE t_l, 
WHERE t_l.has_car = 'y']), 
execute_in_f uture (display ( [Empl] ) ) ) ) 

yielding the response 

Answer : 

Peter Piper 
Zorba Greek 

Key for answer fields: 

A 

A: employee, person 

By making use of the additional fact that the has_car field must be filled 
with either a y or a n, it is also possible to deal successfully with the following 
query: 

user>> Which employees do not have a car? 

finally producing the query 

f orall ( [Empl] , 

impl (sql_select ( [Empl] , 

[SELECT DISTINCT t_l.name, 
FROM EMPLOYEE t_l, 
WHERE t_l.has_car = 'n']), 
execute_in_f uture (display ( [Empl] ) ) ) ) 

and the answer 

Answer : 

Darth Vader 
Geoff Steiner 
Gordon Bennett 
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James Cagney 
Mac the Knife 
Maid Marion 
Naomi Brett-Adams 
Phoebe Waters 
R B N Fielder 
Sammy Davis Junior 

One of the things that make "Doctor on Board" sentences difficult is that 
the correct response is sometimes to report that the sentence cannot be 
translated: the next example illustrates this. 

user>> Which car does Peter Piper have? 

CLARE succeeds in partially translating the query, producing the interme- 
diate formula 

f orall ( [Event , Car] , 

impl (employee_has_car (Event, employeel# ) Peter Piper' ,Car) , 
execute_in_f uture (display ( [Car] ) ) ) ) 

with the accompanying informative message 

Assumptions used in query translation: 

all_cars_ref erred_to_are_company_cars 

It has, however, no way to translate this further into a formula that uses 
an SQL call to access the EMPLOYEE relation; the only rules available for 
translating the employee_has_car predicate require the Car variable to be 
existentially quantified. In other words, they can only apply to formulas 
referring to the existence of cars. The response is now to print an informative 
failure message: 

Warning : 

My definitions of the following predicates may be inadequate 
in this context: [employee_has_car/3] 

Query could not be translated further: 
not attempting an answer. 
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The same method can be used to deal with many "figurative" or "idiomatic" 
constructions. For example, the original logical form for the query 

user>> Which companies have a stake in WHIZ? 

is a faithful encoding of the apparent surface form of the sentence: it asks 
for objects called "companies", which are such that they "have" an object 
called a "stake", which is "in" WHIZ project. To answer the query, it must 
be translated into a form which accesses the PR0JECT_SP0NS0R relation: the 
facts used say in effect that each record in the relation corresponds to a 
suitable instance of a "having" and a "stake". The final executable query 
and result are 

forall ( [Sponsor] , 

impl (sql_select ( [Sponsor] , 

[SELECT DISTINCT t_l . sponsor _name , 
FROM PRDJECT_SPDNSDR t_l, 
WHERE t_l.proj_name = 'WHIZ']), 
display_tuple_in_f uture ( [Sponsor] ) ) ) 

Answer : 

Triton Interstellar Electronics 
Key for answer fields: 
A 

A: company, sponsor 

The next two examples illustrate how CLARE can apply knowledge about 
the way in which it is embedded in its real- world "discourse situation". 
The first one shows an elementary capability in this respect: to be able to 
translate the word current into meaningful database concepts, CLARE must 
know what the date is. 

user>> Show all current projects. 

CLARE's definition of current amounts to saying that an object associated 
with an interval is "current" if that interval includes the present moment. 
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For projects, the relevant interval is the one bounded by their start and end 
dates, which for SRI projects are listed in two fields of the PROJECT relation. 
After informing the user that it is assuming that all projects referred to are 
SRI projects, CLARE ends up with the query 

f orall ( [Name , AccNum] , 

impl (sql_select ( [Name , AccNum] , 

[SELECT DISTINCT t_l.name , t_l.proj_no, 
FROM PROJECT t_l, 

WHERE t_l.start_date <= '15-JUL-93', 
AND '15-JUL-93' <= t_l . end.date] ) , 
execute_in_f uture (display ( [Name, AccNum] ) ) ) ) 

which can be executed to yield the answer 

Key for answer fields: 

[SLT, 3775] 
[WHIZ, 1392] 

[A,B] 

A: project 
B: account 

The next sentence is a more interesting example of CLARE's connection to 
its utterance situation: it illustrates how a verb like show can be treated by 
the framework as an ordinary content word. 

user>> Have you shown me the SLT project? 

The axioms for show, used in translating many of the previous queries, define 
an equivalence between the activity referred to as "showing database objects 
to the user" on one hand, and successfully executed calls to the print_- 
tuple_in_f uture on the other. By providing a log of such calls (implemented 
as a set of clauses for the predicate tuple_printed_in_past), CLARE is able 
to use the same mechanism to answer questions about "showing" actions 
which have already been carried out. In the present case, CLARE performs 
the translation to find out what kind of action would correspond to a "show- 
ing" of the SLT project. The translated query, which is essentially a pattern 
to match against the query log, is 
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tuple_printed_in_past ( [SLT , 3775] ) 

Since the previous sentence has left a record of this type, the response is 
Answer : 

Yes 

The next sentence illustrates an interesting functionality which follows as a 
simple consequence of the translation method: the ability to answer meta- 
questions about the system's knowledge. 

user>> Do you know what the sex of each employee is? 

Questions of the above type are inherently ambiguous between the reading 
which treats them literally as Y-N questions, and the indirect question read- 
ing which makes them politely phrased WH-questions. CLARE's strategy 
is to attempt to translate the "inner" or embedded question, here "What is 
the sex of each employee?" . If this can be done, it informs the user and asks 
whether the answer to the embedded question is also required. 

In the present case, the translation could be carried out successfully, 
giving the following result. 

Assumptions used in query translation: 

all_employees_ref erred_to_are_at_SRI 

kw(forall( [Name, Sex, SexCode] 

impl (and(sql_select ( [SexCode, Name] , 

[SELECT DISTINCT t_l.sex, 

t_l .name , 
FROM EMPLOYEE t_l]) , 
sex_code (Sex , SexCode) ) 
display_tuple_in_f uture ( [Name , SexCode] ) ) ) ) 

The outer devel kw operator is to be read "knows what" or "knows whether" , 
and holds if the argument has been translated into an executable form. Note 
also that the final result of translation includes a call to the predicate sex_- 
code, which relates the internal code used to indicate sex in the EMPLOYEE 
record, to the externally meaningful values Male and Female. The result of 
executing the query is 
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Answer : 
Yes 

Do you want me to to tell you? user>> y. 
Answer : 



Darth Vader Male 

Geoff Steiner Male 

Gordon Bennett Male 

James Cagney Male 

Mac the Knife Male 

Maid Marion Female 

Naomi Brett-Adams Female 

Peter Piper Male 

Phoebe Waters Female 

R B N Fielder Male 

Sammy Davis Junior Male 

Zorba Greek Male 



Key for answer fields: 
A B 

A: employee, person 
B : sex 

Our final examples show CLARE being used to enter information into the 
database by constructing new records, and then describing these records 
back to the user. Since it is often impossible to describe a record in a 
single sentence, CLARE represents the content of the sentences previously 
processed in an intermediate form where fields so far unfilled by specified 
values hold existentially bound variables. Database relations are represented 
as predicates, with one argument place for each column in the real relation. 

We first show how a PROJECT record can be constructed from a series of 
sentences, each of which desribes the filler of one or more field. 

user» FDD is a project. 
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Assumptions used in query translation: 

all_projects_ref erred_to_are_SRI_projects 

After the first sentence has been fully translated, the intermediate form is 

x([X,Y,Z] , 

PR0JECTOF00' ,X,Y,Z)) 

The field indicating the project name has been filled by the atom F00; those 
for the account number and start and end dates have not been specified, and 
thus contain only existentially bound variables. 

The second sentence specifies the project's account, and fills another 
field: 

user» FDD's account is 1234. 

"the account of FDD (the project) is account 1234." 

Resolution paraphrasing make it clear that "1234" is being interpreted as 
"account 1234". After translation (we omit the details), the intermediate 
form is 

x([Y,Z] , 

PROJECT ( 'F00' ,1234,Y,Z)) 

The third sentence describes the fillers of both the start and end date fields 
at once. 

user» F00 started on 1/1/91 and finished yesterday. 

"FDD (the project) started on 1/1/1991 (the day) 
and finished during 14/7/1993 (the day)." 

The final result is the completed database record 

PROJECT ( 'F00 ' , 1234, l-JAN-91 , 14-JUL-93) ) 

It is now possible to ask the system to describe the new record it has built: 
user» Talk about F00. 

"talk about F00 (the project)!" 
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CLARE translates the logical form of the request into a call to the predicate 
talk_about_in_f uture, analogous to print_template_in_f uture. 

talk_about_in_f uture (pro j ect 1# ' F00 ' ) 

CLARE describes the record by filling in predicates in a set of QLF templates 
which have been acquired by generalization from training examples. It avoids 
unnecessary repetition by checking each new sentence before printing to 
make sure it does not logically follow from those previously printed. It 
terminates when the set of descriptive sentences printed is large enough that 
their conjunction is logically equivalent with the record being described. 

Trying to describe a database record: 

"F00 (the project) 's end date is 14/7/1993 (the day)." 
"F00 (the project) 's number is 1234." 

"F00 (the project) 's start date is 1/1/1991 (the day)." 
(The record was fully described) 

Note that the linguistic forms used in the description differ in almost every 
way from those used to enter the record. 

The final example illustrates CLARE's ability to generate questions. We 
repeat the previous example, but this time allowing CLARE to take the 
initiative. The first sentence is the same. 

clare» F00 is a project. 

After this, control is passed to CLARE: 
clare» .ask 

CLARE now attempts to use its domain theory to synthesize questions that 
ask for the values of the unfilled fields in the record. CLARE asks the 
following question, and waits for the user's reply. 

"what is F00 (the project) 's account?" 
answer_please» user» 1234. 

The answer is processed in the same way as any other utterance: resolu- 
tion interprets in in the context of the question just asked by the system, 
producing the following paraphrase: 
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"account 1234 is F00 (the project)^ account." 

Translation then uses this to fill in the "account" field in the record, follow- 
ing which a second question is asked. Once again, processing proceeds as 
normally to fill in the "start date" field. 

"what is F00 (the project) 's start date?" 

answer_please>> user>> 1/1/91. 

"1/1/1991 (the day) is F00 (the project) 's 
start date . " 

The final question demonstrates the flexibility of the interaction strategy: 
CLARE has no problems in coping with an answer which is a complete 
clause, rather than an elliptical fragment. 

"what is F00 (the project) 's end date?" 
answer_please>> user>> FDD ended on 14/7/93. 

"FDO (the project) ended on 14/7/1993 (the day)." 

When the last answer has been processed, the record is complete: the fields 
have the same values as before, 

PROJECT (F00 , 1234, l-JAN-91 , 14-JUL-93) 



Chapter 2 

Interfacing as Translation 



2.1 Introduction 

In this chapter, we will describe at a high level of abstraction the basic 
functionalities provided by CLARE that allow it to be used as a natural- 
language interface to a knowledge base, and in particular to a relational 
database. Before going any further, we will recapitulate at greater length the 



arguments from Section 1.1, and establish more precisely what we mean by 
"natural-language interfacing" . Normally, the problem is thought of as that 
of producing answers to natural-language questions posed to a knowledge 
base (cf. Perrault and Grosz, 1988). Here, we will adopt a more general 
view; we will regard it as the problem of formalizing the relationship between 
1) the contents of a database, and 2) the way in which people use language to 
talk about it. Asking questions about the contents of databases is far from 
being the only way in which language and database can be related; thus apart 
from question-answering, we wish the model to support reasoning that will 
allow at least the following. 

• Responding to natural-language commands. 

• Accepting statements describing new records for the database. 

• Reasoning about whether the database contains the information nec- 
essary to answer an NL question. 

• Indicating whether answers to WH-questions are complete or not, and 
distinguishing between "No" and "Don't know" answers to Y-N ques- 
tions. 
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• Describing existing records in the database using NL. 

• When records are incomplete, formulating NL questions to elucidate 
the information needed to complete them. 

We want the information needed to support these functionalities to be ex- 
pressed declaratively, using some sort of predicate logic; the result will be 
a linguistic domain theory for the database, a theory of how language and 
database are related. Languages are normally based on vague, common-sense 
concepts, databases on precise, formal ones. Relating these two disparate 
systems raises the usual problem of common-sense reasoning: interpretation 
of vague NL concepts in terms of precise database concepts is often only 
possible if additional assumptions, not implied by the explicit linguistic con- 
tent, are made. These assumptions are in general defeasible. In some cases, 
it may be desirable to relay them back to human users. If the scheme is 
to be practically useful, we also want to be able to specify a methodology 
for constructing linguistic domain theories. For the usual software engineer- 
ing reasons, they should also, as far as possible, be modular and re-usable. 
These, in brief, are our top-level goals. We will now make them more specific, 
and relate them to the concrete architecture of the Core Language Engine. 

The CLE, being a general natural language system (rather than one 
tailored to a specific application), constructs representations of utterances 
that essentially mirror their linguistic content. Normally, every content word 
in the utterance will correspond to an occurrence of a word-sense predicate 
in that utterance's TRL representation. Thus for example in the CLARE 
Project Resource Management domain the sentence 

(SI) Show all payments made to BT during 1990. 

gets a TRL representation approximately of the form 

\/X.((3E3A.payment'(X) A make'(E, A, X, bt') A during' {E, 1990)) -» 

3E' .show' {dare' , X) A injuture(E)) (2.1) 

in which the predicates show', payment', make' and during' correspond 
directly to the words show, payment, make and during. In order to carry 
out the command, however, CLARE needs to construct an SQL SELECT 
statement which searches for TRANS tuples where the payee field is filled 
by bt, and the cheque_date field by a date constrained to be between 1st 
January and 31st December, 1990. The gap between the two representations 
can lead to several possible kinds of difficulties. Firstly, the "linguistic" 
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and "database" representations are quite simply very different. Obvious 
problems arise when we frame the task in terms of converting the original 
TRL representation of (SI) into a suitable SQL query. In particular, the 
rules that link specific language-related representation elements to specific 
SQL constructs will in general need to be context-sensitive: in (SI), for 
example, mapping the representation of the word during into a restriction 
on the cheque_date field will involve taking account of the way during is 
used together with the words make and payment at least. 

Alongside of this there is another, more subtle problem. It may be im- 
possible to derive an SQL query that corresponds to the original natural- 
language utterance; or if it is possible, the SQL may not correspond exactly 
to the English. There are three particularly important ways in which this 
can happen, which will motivate much of the following discussion: 

1. A query can be conceptually outside the database's domain. For exam- 
ple, if "payments" in (SI) is replaced by "phone-calls", the interface 
should be able to indicate to the user that it is unable to relate the 
query to the information contained in the database. 

2. A query can be contingently outside the database's domain. Thus if 
"1990" is replaced by "1985", it may be possible to derive a query; 
however, if the database only contains records going back to 1989, 
the result will be an empty list. Presenting this to the user without 
explanation is seriously misleading. 

3. A query may need additional implicit assumptions to be translatable 
into database form. Asking (SI) in the context of our example Project 
Resource Management domain, it is implicitly understood that all pay- 
ments referred to have been made by SRI. If the user receives no feed- 
back describing the assumptions that have been made to perform the 
translation, it is again possible for misunderstandings to arise. 

Keeping in mind the problems we have just discussed, we will next consider 
methodologies previous used to attack these aspects of the natural language 
interfacing task. 

2.2 Related work 

This section examines previous work on the problem of converting between 
"literal" representations of natural-language utterances and representations 
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in terms of database primitives. We will in particular examine three ap- 
proaches, all of which have to some extent influenced the work reported 
here. We list them as follows, with a brief description of each: 

1. Horn-clause methods: the database is encoded as a set of unit clauses, 
and the truth-conditions for the word-sense predicates are defined by 
Horn-clauses which eventually bottom out in the database. 

2. Non-inferential equivalential translation: this approach, first imple- 
mented in the PHLIQUA system, is like ours in deriving database 
queries equivalent to the original logical forms; unlike ours, it does so 
without using general inferential methods. 

3. "Interpretation as abduction": this approach, most widely known from 
the SRI TACITUS system, allows general inference and also assump- 
tion of unproven hypotheses under suitable circumstances. Unlike our 
approach, it attempts however to prove implications rather than equiv- 
alences. 

In the following three sub-sections, we will now describe each approach more 
fully. In the final sub-section, we summarize the way in which they have 
contributed to the scheme described in this thesis. 

2.2.1 Horn-clause approches 

The currently most popular approach is perhaps to attempt to effect the 
connection between LF and database query by encoding the database as a set 
of unit clauses, and then building an interpreter for the logical forms which 
captures the relations between linguistic and database predicates as "rules" 
or "meaning postulates" written in Horn-clause form (cf. e.g. McCord 1987, 
Pereira and Shieber 85). The strength of the Horn-clause method is that it 
allows arbitrary inferences to be used; moreover, since Horn-clause deduction 
can be implemented as a goal-directed backward-chaining algorithm, the 
inference process can be made reasonably efficient. The drawback is that 
Horn-clauses are "if" rules; they give conditions for the LF's being true, but 
(as pointed out in Konolige 1981), they lack the "only if" half that says when 
they are false. This means that they can normally only be used to justify 
positive answers to questions; there is no easy way to distinguish between 
"no" and "don't know" in a pure Horn-clause theory. It is of course possible 
to invoke the Closed World Assumption (CWA); in this interpretation, finite 
failure is regarded as equivalent to negation. Unfortunately, experience also 
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shows that it is extremely difficult to write meaning postulates for non-trivial 
domains that are valid under this strict interpretation. 

For these reasons, Scha (1982) concludes that Horn-clause methods are 
insufficient; this is regretable, in view of their many obvious advantages. 
One way of viewing the present piece of work is as an attempt to redeem the 
Horn-clause approach from Scha's objections. 

2.2.2 Non-inferential equivalential translation 

The second line of attack we will consider could be called "non-inferential 
equivalential translation": the basic idea is to derive a query which is log- 
ically equivalent with the orginal logical form, but to do so without using 
general inferential methods, on the grounds that these cannot be imple- 
mented in a sufficiently efficient way. The best-known systems to embody 
variants of this approach are PHLIQA (Bronnenberg et al 1980) and the 
systems developed at BBN during the mid-80's (Stallard 1986) where the 
method is referred to as 'recursive terminological simplification'. In both of 
these there is restricted inference amounting to a form of type-checking. The 
advantage of equivalential translation methods in general is that they justify 
both positive and negative answers. However, the lack of general inference 
results in a loss of expressiveness which can most obviously be illustrated by 
variants of the so-called "Doctor on Board" problems (Perrault and Grosz, 
1986) caused by the presence of existential quantifiers. We will return to 
this point in section |3.7| . 

We should mention at this point a little-known paper of Konolige from 
1981, which also formulates the problem in terms of equivalence between 
logical form and database query; particularly with regard to treatment of 
proper names we have borrowed from Konolige's idea to some extent. The 
paper, however, is written entirely at the level of denotation, and makes no 
mention of inference methods suitable for concretely solving the problem as 
posed. 

2.2.3 "Interpretation as abduction" 

The third strand of research we will examine attacks a problem ignored by 
both of the first two: as already pointed out, it is not in general possible 
to justify a sound inferential connection between logical form and database 
without making additional unproven assumptions, which later information 
may potentially invalidate. The most obvious way to extend an inferential 
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framework to account for this objection is to allow leaf-nodes in proofs to 
include not only axioms from the background theory but also formulas which 
it can be regarded as reasonable to assume; in order to prevent explosion of 
the search-space, it is normally necessary to place constraints on the formu- 
las which can potentially be assumed. The best-known variant of this idea is 
that pioneered by Hobbs and his colleagues under the name of "Interpreta- 
tion as Abduction" (Hobbs et al 1988) and embodied in the SRI TACTITUS 
system. (Other similar work is that of Charniak and Goldman (1988)). The 
basic mode of operation of TACITUS is to attempt interpretation of the 
logical form by attempting to construct a proof of its correctness using the 
background theory and the "cheapest" possible set of additional assump- 
tions; for the idea to make sense, a cost function is defined on the space 
of logical formulas which makes intuitively plausible formulas cheaper than 
intuitively implausible ones. We will make use of this general idea, though 
in a somewhat different context, since we are dealing with equivalence rather 
than implication. 

2.2.4 Relationship of AET to earlier work 

Having briefly described what we view as the main precursors of our work, 
we now indicate more exactly how we consider that it combines and improves 
on them. AET can be viewed as a version of the equivalential translation 
framework used in PHLIQUA and Konolige's paper, extended to be able to 
employ general inference methods of the kind used in Horn-clause systems to 
justify equivalence between LF and database form. This depends on coding 
the relationship between LF and database forms not as Horn-clauses but 
as "definitional equivalences" , conditional if-and-only-if rules of a particular 
form. Our approach retains computational tractability by limiting the way 
in which the equivalences can take part in deductions, roughly speaking by 
only using them to perform directed "translation" of predicates. However 
we still permit nontrivial goal-directed domain reasoning in justifying query 
derivation, allowing, for example, the translation of an LF conjunct to be 
influenced by any other LF conjuncts, in contrast to the basically local trans- 
lation in PHLIQA. This approach deals with the first two points described 
at the beginning of the chapter without recourse to the CWA, and simulta- 
neously allows a clean integration of a version of the "abductive" reasoning 
used in TACITUS. As we shall see, it also makes it possible to use substan- 
tially the same framework to achieve interfacing functionalities other than 
question-answering. The main technical problems to be solved are caused by 
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the fact that the left-hand sides of the equivalences are generally not atomic. 

The rest of this chapter is structured as follows. Section ^3 begins by 
laying out the basic ontology underlying linguistic domain theories of the 
types we will consider. After this, Section 2.4 describes the approximate 
formal appearance of these theories, and presents the key technical concept 
of effective translation. The central section is 2.5, where we give an overview 
of the interface system, concentrating on the denotational and functional 
aspects; taking them one at a time, we show how the interface functionalities 
listed at the beginning of Section 2.1 can be formalized as tasks of the form 
"for some formula P, find a formula P' of a specified type, such that P and 
P' are equivalent given the linguistic domain theory and some permitted 
assumptions." We will refer to tasks of this kind as "performing abductive 
equivalential translation (AET) on P" . Finally section ^1] considers the 
connection between AET and the Closed World Assumption. 



2.3 Ontological issues 

We start by defining the basic ontology underlying the linguistic domain 
theory; the ideas are closely related to those proposed in (Konolige 1981). 
We assume as usual that there is a set of objects, O, and a set of relations 
obtaining between them, R. O will contain all the things that the predicates 
in logical forms range over — the things, like suppliers, parts, projects, 
payments, deliverables, etc. that natural language refers to. This includes 
events. Similarly, R will contain all the relations obtaining between elements 
of O that we will wish to refer to. 

There will be no particular need in what follows to be much more specific 
about exactly what can and cannot belong to O and R, though this is 
obviously not a trivial matter. We will however be interested in picking out 
certain distinguished subsets of these two sets which have direct relevance to 
database interfacing. We take the position that databases are also objects 
in the world, consisting of finite collections of rows of marks; this is not a 
common viewpoint at the moment, but we think it corresponds well to the 
naive view of "what a database is" . We consequently assume the existence 
of a subset Odb of O consisting of database objects, which will be numbers, 
strings, date representations, and other "marks" that can be found filling 
fields in database records. Similarly, we will assume the existence of a subset 
Rdb °f R) which will be the database relations. Database relations are 
defined by the database's internal structure in terms of tuples: a database 
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relation D holds of a list of arguments Argi iff there is a tuple of type D in 
the database whose fields are filled by the Argi. Since little can be done with 
database objects without recourse to elementary arithmetic and an ability 
to display results, we assume two more distinguished subsets of R. Arith 
will be the relevant arithmetic relations (like "being numerically less than" ) 
that can obtain between members of O^b- Exec will be a primitive set of 
relations which the interface can cause to hold by performing actions. A 
typical relation in Exec would be the one that holds between a database- 
object, and a time and place at which the interface displayed it. 

In what follows, the distinction between database objects, the non-data- 
base objects they name, and the terms in the linguistic domain theory that 
refer to both of them will be central. Thus for example we distinguish 
between 

• a transaction (a non-database object, an event in the exterior world) 

• the term referring to the transaction in the linguistic domain theory 

• the database object (a number) that is the transaction's ID 

• the term in the theory referring to the database object. 

Although these distinctions may not immediately seem necessary, they are in 
fact motivated by typical properties of real databases. Database objects are 
often codes or non-unique names, that cannot simply be treated as names 
in a first-order theory; for example, the same number, occurring in different 
fields in a relation, can be related to distinct real-world entities, or (if used 
as a code value), to a property of an entity. 

The linguistic domain theory relates database objects with real- world 
objects, allowing us to draw conclusions about the properties of the real- 
world objects by examining the database records. Less obviously, it can also 
allow us to draw conclusions about properties of real-world objects from 
the lack of records of a particular type in the database. This amounts to a 
principled generalization of the "closed world assumption" , and is described 



further in section 2.t. The linguistic domain theory can also partially model 
the interaction between system and user, by defining a relation between 
predicates holding in the "utterance situation" (the real-world situation in 
which the user is interacting with the interface), and the executable relations. 
For example there are real-world predicates which correspond to verbs like 
"show" and "list", which are commonly used in commands (e.g. "Show me 
all payments over £500"); these are related by the linguistic domain theory 
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to the primitive executable relation of displaying characters on the screen. 
Treating the utterance situation uniformly as part of the domain adds both 
conceptual elegance and a real increase in the interface's scope; so it is for 
instance possible to deal with queries like "Which of the payments that you 
showed me in answer 12 were made this year?" in a principled way. 

2.4 LDTs and effective translations 

At a pre-theoretical level, our characterization of the NL interfacing func- 
tionalities is actually a very simple one: it is only the technical details that 
will prove complex. The key notion is that of "translation". Given an 
interfacing task, described in one vocabulary, we wish to translate it into 
an equivalent task, described in another vocabulary. Thus for example the 
"question-answering" task is of the form "produce an answer to the question 
whose logical form is P" ; we wish to translate this into an equivalent task of 
the form "execute the database query P', and print the results in a readable 
way". Here, the original task is expressed using predicates corresponding 
to word-senses; the problem is to translate it into a task expressed using 
predicates corresponding to database relations, arithmetical operations and 
primitive executable relations. What we want to do now is to express these 
ideas in formal terms, so that we can then realize them as an inference prob- 
lem. In particular, we want to introduce linguistic domain theories so that 
translation can be regarded as logical equivalence with respect to a theory. 
We will start by sketching the appearance of a linguistic domain theory, and 
defining the formal concept of effective translation. Throughout most of the 
thesis, we will regard it as sufficient to allow the target representation (the 
result of performing the translation) to be a predicate calculus expression 
that treats database relations as predicates; in appendix |C], we briefly review 
the module that performs the final conversion into executable SQL queries. 

2.4.1 Basic form of linguistic domain theories 

Since we are primarily interested in establishing equivalences (rather than 
implications), it makes sense to write the LDT as far as possible using for- 
mulas which themselves are equivalences. For various reasons, it turns out 
that it is convenient to allow these equivalences to be conditional; to limit 
computational complexity, we will only allow their left- and right-hand sides 
to be existentially quantified conjunctions of atomic formulas. Thus in sum- 
mary, the greater part of an LDT will be composed of formulas of the general 
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appearance 

\/x.{Left = Right) <— Conds 

where Left, Right and Conds are existentially quantified conjunctions. Lin- 
guistic domain theories typically also contain Horn-clause axioms and dec- 
larations of functional relationships between arguments of predicates (these 
are described in detail in section p. 6. 2 ). 



It is permitted during inference to assume goals abductively, at a cost 
depending both on the goal and the context in which the assumption is 
made. We do not attempt to define a formal semantics for the notion of 
abductively justified inference: we merely assume that costs are assigned 
according to some scheme that generally makes low-cost proofs intuitively 
more appealing than high-cost ones. Since abductive assumptions are in any 
event made explicit to the user of the system, we view the costs essentially 
as heuristics to control the order in which the space of possible proofs is 
searched. The range of goals that may be abductively assumed is controlled 
by declarations of the form "goal G may be abductively assumed with cost 
C and justification J in a context where Conds can be proved to hold". 
Here, G is an atomic formula, C a number and Conds an arbitrary formula; 
J, the "justification", is a tag that can be used to identify the assumption 
to the user. An assumption can be identified as inconsistent if a proof of 
the negation of the assumed goal can be found in the context in which 



it was assumed (cf Section 3.5). To the extent that this is possible (cf. 



Section 5.1.3| ), CLARE thus has a limited ability to handle normal defaults. 



Experimentation with CLARE seems to indicate that one can profitably 
divide abductive assumptions into at least three distinct types; we illus- 
trate using the example PRM domain, which covers a project and payment 
database for SRI Cambridge. In the PRM domain, it is reasonable to assume 
(lacking evidence to the contrary) that "project" is equivalent with "project 
at SRI Cambridge". The content of assumptions of this kind is that the 
speaker means something more specific than what was actually said. We 
consequently refer to them as "specializations". In contrast, it is also rea- 
sonable to assume that "payment" means "SRI payment made during the 
period covered by database records". In this case, however, it seems in- 
tuitively less clear that the speaker intended to use the word in the more 
restricted sense, and it is more appropriate to assume that the database is 
limited in a way which the speaker may not be fully aware of. We will call 
assumptions of this kind "limitations". Finally, it may sometimes be ap- 
propriate to make assumptions that can actually be incorrect: for example, 
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we assume that completion dates for future deliverables have been correctly 
estimated. We call these assumptions "approximations" . Distinguishing be- 
tween different kinds of assumption will become important later on, when 
we consider issues regarding the completeness of answers to questions. 

2.4.2 Effective translation 

We now introduce the key formal definition. We write T to symbolize a 
linguistic domain theory, and let F source be an arbitrary formula; then we 
define F tar get to be an effective translation of F source iff there exists a set of 
abductive assumptions A such that 

r U A (F source = Ft ar g e i) (2-2) 

and 

• Each assumption in A is acceptable in the context in which it is made. 

• There is a finite proof procedure for determining the truth of Ft ar g e i. 

The question of whether or not a finite proof procedure exists for a formula, 
given a theory, is of course undecidable in general; CLARE only attempts 
to solve a simple subcase of this problem. 

The first criterion that must be met is that all predicates in F tar get must 
be potentially finite: by this, we mean that they should have the property 
that for at least some combinations of instantiation of their arguments there 
are only finitely many instantiations of the remaining arguments that make 
them true, and that these new instantiations can be found within bounded 
time. Thus the minimum requirement is that if all the arguments are ground 
it is possible to determine the truth of the relation within bounded time. 
There are in practice three kinds of potentially finite predicates in a linguis- 
tic domain theory: database predicates, arithmetic relation predicates, and 
primitive executable predicates. We examine each of these in turn: 

Database predicates These are predicates directly corresponding to the 
database relations Rdb ; a database predicate holds of its arguments iff 
the database relation has a row with those arguments. The finiteness 
of database predicates follows from the finiteness of the corresponding 
database relations. Database predicates are consequently always finite, 
irrespective of their instantiation. 
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Arithmetic relation predicates These correspond the arithmetic rela- 
tions in Arith, such as addition, subtraction, and inequality. In gen- 
eral, arithmetic relation predicates are only finite if all or all but one 
of their arguments are instantiated. For example, if X is instantiated 
to a given number, there is an infinite set of values for Y such that 
X < Y holds. If both X and Y are fixed, however, the truth or falsity 
of X < Y can in practice be determined in bounded time. Similarly, if 
X is specified, then there is an infinite set of values for Y and Z such 
that X + Y = Z. If Y is also specifie, however, there only one such Z, 
which can again in practice be found in bounded time. 

Primitive executable predicates In order to be able to reason about 
CLARE's ability to perform actions like displaying of objects, there 
is a set of predicates which correspond to the primitive executable 
relations Exec. We assume that these predicates are finite for instan- 
tiated actions. Thus for example we will assume that it is possible 
within a bounded time to ensure that any specified database object is 
displayed. 

Since the finiteness of some predicates depends on their instantiation, 
the existence of a finite proof procedure generally depends on being able to 
find a evaluation order which ensures that conditionally finite predicates are 
sufficiently instantiated by the time they are queried; CLARE can search 
for suitable evaluation orders by permuting the order of evaluation of con- 
junctions. For example, if TRANS/3 is a database predicate then the 
strategy "find an X such that X > 100, then find values of Y such that 
TRANS(john, X, Y)" is not a finite strategy; however, reversing the order 
to make the strategy "find X and Y such that TRANS(john, X,Y), then 
determine whether X > 100 holds" is finite. The search is carried out us- 
ing a simple abstract interpretation method, which uses meta-information 
about finiteness of predicates with respect to different instantiation patterns 
to mimic the behaviour of the real execution module. This part of the system 
is described further in section |5.3| . 

2.5 Formalizing interfacing functionalities 
2.5.1 Yes/No questions 

We are now in a position to describe formally the various interfacing func- 
tionalities. The simplest one to begin with is that of answering a Y-N ques- 
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tion. The formal statement of the problem is as follows. We are given a 
formula, Fn ng , which is the logical form of a Y-N question to be answered. 
We wish to find a formula F eva i and a set of permissible assumptions A, such 
that F eva i is an effective translation of Fn ng modulo A in the sense defined 
in Section |2.4.2 . There are several possibilities. 



• No such F eva i can be found: the answer is Don't know. 

• A is empty and F eva [ can be proved: the answer is Yes. 

• A is empty and F eva [ cannot be proved: the answer is No. 

• A is non-empty, but some member a of A is such that the negation of 
a can be proved: the answer is Cannot answer question, because 
this violates the assumption a. 

• A is non-empty and F eva i can be proved: the answer is Yes, condi- 
tional on the validity of the assumptions. 

• A is non-empty and F eva [ cannot be proved: the answer is No, con- 
ditional on the validity of the assumptions. 

If assumptions have been made, the user can be told what they were. An 
example of each case, taken from the PRM domain, follows. 

• The question is Does Peter have a dog?. There is no effective trans- 
lation of the logical representation of this question, so the answer is 
Don't know. 

• The question is Is Peter an employee at BT?. There is an effective 
translation of the logical representation of this question, but it assumes 
that Peter is an employee at SRI, which contradicts the requirement 
that he is also an employee at BT. So the answer is Don't know, be- 
cause this violates the assumption that all employees referred 
to are at SRI. 

• The question is Does Peter have a car?. Peter is an employee, and 
there is an effective translation to a query that accesses the EMPLOYEE 
relation. The translated query can be proved, so the answer is Yes. 

• The question is Does Gordon have a car?. This is the same as the 
previous case, except that Gordon does not have a car according to 
the database, and the effective translation cannot thus be proved. The 
answer is No. 



36 



CHAPTER 2. INTERFACING AS TRANSLATION 



• The question is Has Peter booked less than 200 hours to CLARE? 
Peter is an employee, and CLARE is a project, so there is an effective 
translation to a query that accesses the TIMESHEET relation under the 
assumption that the time referred to was booked during the period for 
which records were kept. The database reveals that only 165 hours 
were booked during this period, so the answer is Yes, conditional 
on the validity of the assumptions. 

• The question is Has Peter booked less than 100 hours to CLARE? The 
assumption used when translating is the same as in the last example, 
and the answer is No, conditional on the validity of the assump- 
tions. 

2.5.2 Commands and WH-questions 

The functionality of responding to a natural language command can be cap- 
tured by a fairly simple extension of the previous definition. We will assume 
that the logical form representation of a command is a formula which is true 
if the command will be carried out at some future time. Once again, we let 
Fling De the logical form of the command, and the task is to find an effective 
translation F eva i modulo a set of assumptions A. F eva i will usually be a 
formula that contains primitive evaluable predicates. 

Answering WH-questions can be treated as a special case of responding 
to commands, if we assume that the logical form of a WH-question is of the 
type Xx.Q(x), where Q(x) holds iff x is an object satisfying the question. 
Thus for example the logical form for Which payments in June were over 
£1000? will be roughly 

Xx. payment' (x) A in \x, june') A over'(x, 1000) (2-3) 

The asking of a WH-question can be regarded as a command to display all 
the objects that would be answers to it. (The issues involved are discussed 
at greater length in Appendix [A|; cf. also (Rayner and Janson 1987)). So if 
Xx.Qn n g(x) is the logical form of the question and displayed Jn_f uture(x) is 
a predicate that holds if x is displayed at some future time, then the question 
can be regarded as equivalent with a command whose logical form is 

\/x.Q(x) — > 3t.displayed-in_future(x) 

The different cases that can arise in responding to a command or WH- 
question are fairly similar to those for responding to Y-N questions. We 
summarize, this time without examples: 
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• No such F eva i can be found: the answer is Don't know how to 
respond. 

• A is non-empty, but some member a of A is such that the negation 
of a can be proved: the answer is Cannot respond, because this 
violates the assumption a. 

• A is empty, or only contains "specialization" assumptions, and F eva i 
can be proved: the response is to perform all the necessary actions (e.g. 
displaying objects) and inform the user that the response is complete. 

• A is empty, or only contains "specialization" assumptions, and F eva i 
cannot be proved: the response is to inform the user that it is impos- 
sible to carry out the command. (This cannot occur with questions). 

• A contains "limitation" or "approximation" assumptions, and F eva i 
can be proved: the response is to perform all the necessary actions and 
inform the user that the completeness and/or accuracy of the answer 
depends on the assumptions. 

• A contains "limitation" or "approximation" assumptions, and F eva \ 
cannot be proved: the response is to inform the user that it is impos- 
sible to carry out the command if the assumptions are correct. 

A few words are in order to explain why different types of assumption 
can give rise to different responses. The intuitive justification is that "spe- 
cialization" assumptions are ones where the reasonable default is to trust 
that the user intended them to be assumed; "limitation" and "approxima- 
tion" assumptions are ones where this default is not clearly appropriate. 
The lack of a clear dividing line between the various types of assumptions 
mirrors the lack of clear criteria that can be used to decide when a set of 
answers to a WH-question can be regarded as potentially "incomplete" ; the 
incompleteness is relative to the user's intent, which can only be guessed at. 

A more advanced treatment might examine the previous discourse when 
deciding whether or not to warn the user about potential incompleteness 
of information. For example, a typical "limitation" assumption is that all 
events of a certain type (e.g. transactions) that are referred to are within 
the period for which records are available. The first time this point becomes 
relevant to translating a query, it is reasonable to inform the user, specifying 
the exact period in question and warning that the answer is based on po- 
tentially incomplete information. On subsequent occasions, it may be more 
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helpful to assume that the user is already aware of the assumption and has 
taken it into account when phrasing her question. 

2.5.3 Statements describing new information 

At a pre-theoretical level, the intended behaviour when responding to a 
declarative statement is to attempt to interpret it as a description of a new 
tuple (or set of tuples) that are to be added to the database. However, one 
of the immediate problems that arises when formalizing this simple picture 
is that more than one sentence is normally required to describe a tuple 
fully; the natural unit for describing a tuple is perhaps the paragraph. This 
clashes to some extent with the sentence-oriented processing strategy in the 
rest of CLARE. The compromise position taken is to treat each sentence as a 
component in a tuple description that is being built up successively, as part 
of a small discourse. When responding to a given declarative sentence S, we 
will thus assume that a logical formala Aj n is available, which summarizes the 
content of the sentences previously processed in the current tuple-description 
discourse. We will call Aj n the logical discourse context. If processing of S 
does not result in a full tuple description being produced, a new formula A out 
may be produced which summarizes the content of the current discourse after 
processing of S (cf also Section 3.6.3| ) . We will also need a criterion for what 



it means for a formula to be a tuple description: we will say that F is a tuple 
description iff F is a predication whose predicate symbol refers to a database 
relation, and all of whose arguments are terms referring to database objects. 

This brief discussion should serve to motivate the following breakdown 
into cases. The starting point is a declarative sentence with logical form 
Fu ri g, and the current contents of the logical discourse context Aj n . We now 
attempt to find A, A and A' such that AAA' is an equivalential translation 
of 

Fling A Aj n modulo j4, and A is a conjunction of tuple descriptions. The 
cases are: 

• Fling A Aj n can be proved false. The user is informed, and no other 
action is taken. 

• Fu n g A Aj n cannot be proved false, but no such A and A' can be found: 
the user is informed that it was so far impossible to construct any 
tuple, and the logical discourse context is updated to be Fn ng A Aj n . 

• A suitable A and A' can be found; the tuples described by the A 
are added to the database, the user is informed that tuples have been 
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constructed using the assumptions A, and the logical discourse context 
is updated to be A'. 

The first case can normally only arise when function information can be used 
in effect to show that two distinct records would have the same primary key 



(cf Section 3.6,2 and the beginning of Section 4.2), 

It is arguable that in the second case the user should be informed if it 
is impossible to find a translation F^b of Fn ng A Aj n all of whose predicates 
are potentially finite, on the grounds that the statements already received 
during the present discourse cannot be translated. The objection is that fur- 
ther statements may resolve the problem and allow translation to database 
form to occur. To take an example from the PRM domain, the first sen- 
tence in the discourse could be Clara is a woman; this cannot be translated 
into database predicates, since information about sex occurs in two distinct 
relations, EMPLOYEE and PAYEE. If, however, the second sentence is Clara is 
an employee, the conjunction of the two sentences can be translated. There 
are other conceivable reasons why the logical discourse context at an in- 
termediate point in the discourse may be untranslatable, for instance that 
a statement is being made only to provide information that will allow a 
subsequent statement to be translated. It is in general clear that a tight 
characterization of the functionality of responding to declarative sentences 
is not straightforward. Although the user's ultimate goal can be assumed 
to be that of describing a tuple, there are many indirect ways in which this 
can be achieved, and it can be difficult to distinguish cases where commu- 
nication has broken down from cases where the user's intended strategy for 
describing the tuple is not yet apparent. 



2.5.4 Meta-questions 



Both Y-N and WH questions can occur embedded in meta-questions of the 
form "Do you know QT\ e.g. "Do you know how many people work on 
CLARE?", "Do you know who received the largest payment?", "Do you 
know whether there were any payments on 1/11/91?". The strategies used 
to respond to Y-N and WH-questions can extended in a straightforward way 
to cover these cases; the intuitive idea is that the system can be said to "know 
Q" if it would be able to produce a complete answer to Q according to the 
criteria described in Sections 2.5.1 and 2.5.2. There is an important point 



here on which we are implicitly relying: we assume that "knowing what X is" 
is in the context of database-question-answering equivalent with "knowing 
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how to display X". In general, there are many good reasons why "knowing 
what X is" should be interpreted in a context where the information will 
be put to a specific use; in a more advanced treatment of meta-questions, it 
might be necessary to reason about possible ways in which the information 
would be used. For example, "knowing where X lives" could mean any of 
"knowing how to get to X's house by car", "knowing how to get to X's 
house on foot", "knowing how to give instructions for reaching X's house" 
or "knowing how to display X's postal address" . It is a matter of everyday 
experience that these conditions need not coincide. 

With the caveats just mentioned, the problem of dealing with meta- 
questions is simple. If Fu ng is the logical form of Q, it follows from the 
discussion in 2.5.1 and 2.5.2 that a sufficient criterion for producing an affir- 
mative answer to "Do you know Q?" is that there is an effective translation 
F eva [ of Fn n g modulo a set of assumptions A, where A contains only "spe- 
cialization" assumptions. There are also several ways in which inability to 
meet this criterion can be meaningful to a user. If translation can only be 
carried out by assuming a "limitation" or "approximation" assumption, or 
by making an assumption whose negation is implied by its context, then the 
offending assumption normally constitutes a good explanation of "why the 
system doesn't know". 

The cases for different types of response are simple variants of those for 
normal questions. So for example if database records only extend back to 
17/8/88 it may only be possible to translate the predicate corresponding to 
the word "payment" into an expression involving the transaction relation if 
it is assumed that the payment was made after 17/8/88. In this case the 
meta-question "Do you know whether there were any payments on 5/5/86?" 
will receive the answer No, because this violates the assumption that 
all payments referred to were made after 17/8/88. 



2.5.5 Generating statements and questions 

Finally, we consider the functionalities of generating statements and ques- 
tions. If Sdb is a database formula that we wish to realize in language, the 
problem is to find a set of NL statements Si (i = l...n) with logical forms 
Li , and an acceptable set of assumptions A such that 

This is fairly obvious; more interestingly, a very similar treatment works for 
questions. For example, if Qdb is a formula composed of database predicates, 
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and containing a free variable x, then Xx.Qdb can reasonably be thought of 
as an abstract representation of the WH-question "What x satisfies Qd&?" . 
Assuming as before that the logical form for a WH-question is a lambda- 
abstraction, the problem of finding a linguistic realization of Xx.Qdb can 
be formalized as that of finding a single natural-language question Q with 
logical form Xx.Qi ing (x), and an acceptable set of assumptions A such that 

r U A => Vx.(Qu n g(x) = Qdb{x)) 

The issues involved are discussed at greater length in chapter ^. 

2.6 The Closed World Assumption 

This section will briefly consider the question of how the Closed World As- 
sumption fits into the picture we have constructed. To make the discussion 
concrete, we will initially focus on the case of Y-N questions. 

We start with a logical form, Fn ng , for which we assume that we can 
find an effective translation F eva i, and assume further that it turns out that 
there is no proof of F eva [. Inability to prove F eva [ will imply that it is false, 
since we have assumed the existence of a finite proof procedure; this in turn 
implies (if the abductive assumptions are granted) that Fu ng is false, since 
F eva i and Fu ng are equivalent. With regard to the CWA, the interesting 
thing to consider is the part played by the database predicates that occur 
in F eva [. Knowledge of the database predicates is complete, since they have 
"trivial" semantics, only referring to the existence of database tuples and 
not directly to the rest of the world; they are closed by construction and 
the Closed World Assumption may safely be used on them. However, the 
predicates in Fn ng are in general not closed. We will now examine in more 
detail how the connection between the "closed" predicates in F eva \ and the 
"open" predicates in Fi ing is defined. 

In practice, the key step in proving the equivalence between Fu ng and 
F eva [ is usually of the following form. There are two predicates P(x, y) and 
Prec(n x ,n y ), whose intended semantics are, respectively, "x and y stand in 
relationship P" and "It is recorded in the database that objects named n x 
and n y stand in relationship P". Thus P rec is closed, but P isn't. The two 
predicates are related by a domain axiom of the form 

C{y) -> (P(x,y) = 3n x ,n y .namei(x,n x ) 

Aname2(y, n y ) 

AP rec (n x ,n y )) (2.4) 
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Here, each namei(a,n a ) (i = 1,2) is a predicate that relates an object a 
and the identifier gned to it according to naming convention i. (As 

pointed out above in section |2.3| , it is important to take account of the fact 
that the same identifier can name different objects in different contexts). 
C(y) defines a sufficient condition for P(x,y) to have been recorded; for 
example, y might be a date and C(y) could say that y is within the period 
for which records have been kept. 

Now suppose that P(x, y) occurs in Fu ng conjoined with some expression 
D(y), where D(y) can be proved to imply C(y). Then fl2.4| ) can be invoked to 
justify replacing P(x,y) in Fu ng with 3n x ,n y .namei(x,n x ) f\name2{y,n y ) A 
Prec( n x, n y ) while maintaining equivalence. (This will be justified in detail in 
Section 3.2.1 ). The net effect is that the CWA with regard to the predicate 
P has been made conditional on the its context of use. Equivalences of 



type (p.4j) are discussed further in section [4.5 . 

The above analysis of how the CWA relates to Y-N question can be 
extended fairly simply to WH-questions as well. We will in fact distinguish 
between two types of WH-question: "what" or "which" questions, which 
involve finding objects, and "how many" or "how much" questions, which 
involve counting or summming. In the first case, our treatment, as already 
indicated, involves recasting the question in a form where it is a command 
to display objets from the database to the user. Again, it will normally be 
the case that the predictes used in the orginal query are open: however, 
the effective translation will only refer to a closed world in which names are 
transferred from the database to the display screen. 

With regard to "how many" questions, the original question will in gen- 
eral refer to counting objects in the exterior world which satisfy some prop- 
erty P. Here, construction of an effective translation will rely on axioms in 
the domain theory that place the counted objects in one-to-one correspon- 
dence with database objects P' . One way of looking at this is that these 
axioms constitute a local unique name axiom, which encodes the constraint 
that names are unique over the set of objects being counted. Once the prob- 
lem is reduced to counting database objects, it is again possible to solve it 
by examining the actual database. The point is that the intended model 
for the theory is finite and available for inspection, so it is feasible to find 
and count the extension of the property P' - an option not available for a 
general theory. 



Chapter 3 

AET 



3.1 Introduction 

We will now consider the actual computational mechanisms used to effect 
the task of carrying out abductive equivalential translation. The guiding 
example we will have in mind here is that provided by logic programming: 
one of the things that has made Prolog a success is the clear procedural 
model that can be associated with a Horn-clause program. This chapter will 
attempt to do the same thing for a slightly richer kind of theory; it describes 
a kind of logic-programming with equivalences. 

More exactly, recall that the main body of the declarative knowledge 
used is coded as a set of conditional equivalences, formulas of the typef] 

Conds -» ((3x.I\ A P 2 A P 3 -) = P') (3.1) 

The attractive aspect of this type of equivalence stems from the fact that it 
can be given a sensible interpretation in terms of the procedural notion of 
"translation" . The intuitive idea is that is that (|3.l| ) can be read as "Pi can 
be expanded to P' if it occurs in an environment where P% A P3... A Conds 
can be inferred". The "environment" is provided by the conjuncts occurring 
together with P\ in the original logical form, other meaning postulates, and 
the contents of the database; we will call it the conjunctive context. The 
result is a framework in which arbitrary domain inference can play a direct 
role in justifying the validity of the translation of an LF into a particular 
database query. 

1 Quantification over the x on the left-hand side will often in practice be vacuous. In 
this and other formulas, we assume implicit universal quantification over free variables. 
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The chapter is structured as follows. Section |3.2| defines the basic formal- 
ization of AET in terms of translation schemas, formulas that allow trans- 
lation of a complex formula to be defined in terms of translation of its com- 
ponents. Initially, higher order-order constructs and abductive proofs are 
ignored; section |3.3| gives a simple illustrative example. After this, Sec- 



tion 3.4 then extends the framework to cover translation of higher-order 
formulas, and Section 3.5 describes how translation can be made abductive. 
Section 3.6 describes the simplification module. Section 3.7 considers the 
way in which AET's handling of existential quantification allows it to deal 
successfully with the "Doctor on Board" problem, the standard test-case 
in the literature. The discussion up to this point has been at an abstract 
level; Section |3,8| now sketches the implementation of the AET interpreter 



in Prolog. Finally, Section 3.6 describes a simple AET debugger, based on 
the Prolog debugger. 

Remark on notation. This chapter describes the central ideas of AET 
at an abstract and fairly implementation-independent level, and to empha- 
size this we will usually present logical formulas in standard notation. When 
referring to examples from the implemented system, however, it will some- 
times be convenient to employ the concrete Prolog syntax used by CLARE, 
writing and(P,Q) instead of P A Q, exists (X,P) instead of 3X.P, and so 
on. In the next chapter, where we refer constantly to examples from the 
system, we will switch almost exclusively to the concrete syntax. We hope 
that this lack of consistency will not cause the reader undue difficulties. 



3.2 Formalization of AET 

This section describes the formal basis for AET; it shows how conditional 
equivalences of type (|3.1| ) can be used to perform recursive goal-directed 
translation of formulas according to a simple and well-defined scheme. We 
begin with a manoevre that will turn out to result in a great simplification of 
the technical problems. Instead of allowing arbitrary formulas of type ( |3.ip , 
we constrain them by demanding that one of the following two conditions 
holds: 

1. The left-hand side is a conjunction of atomic formulas. 

2. The left-hand side is an existentially quantified atomic formula, and 
the conditions are trivial. 
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The two types of permitted formulas are illustrated in ( j3^ ) and ( |3.3| ): 

Conds -» ((Pi A P 2 A P3-) = P') (3.2) 
3x.(P x ) = P' (3.3) 



We will refer to equivalences of type (|3.2| ) as universal equivalences, and 
those of type ( |3.3| ) as existential equivalences. Allowing only these types of 
equivalence actually entails no loss of generality, since an expression of the 
form 

Conds -► ((3x.Pi A P 2 A P 3 . . .) = P') (3.4) 
can be rewritten, introducing a new predicate P123, as the two equivalences 

Vx.(Conds -» ((P x A P 2 A P 3 . . .) = Pi 23 (x))) (3.5) 

of type (|3.2D , and 

(3x.P 123 ) = P' (3.6) 

of type (^^) • The considerations relevant to use of universal and existential 
equivalences turn out to be quite different in nature. We will consequently 
discuss them seperately, starting with the universal ones. 

3.2.1 "Universal" equivalences and translation schemas 

We first present the basic motivating example, which we will quickly general- 
ize; we will show how a "universal" equivalence - an equivalence of type ( |3.2[) 
- can be used to translate a conjunction P A R in a way that allows R nat- 
urally to be part of the context in which P is translated. Suppose then that 
we are given our equivalence 

Conds -► (Pi A P 2 A P 3 ...) = P' (3.7) 

and that P is a ground goal that unifies with Pi with most general unifier 
9, i.e. 9 (Pi) = P. Suppose also that R implies 6>(P 2 A P 3 ... A Conds). Then 
we claim that 

RAP = RA9(P') (3.8) 

The proof is simple. In the 4= direction, we have that R implies 9(Conds) 
by hypothesis. Also, fl3.7|) means that 9(P' A Conds) implies 9(Pi), which 
by hypothesis is equal to P, from |3.2| . Hence R A O(P') implies P and thus 
PAP. 
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In the =>• direction we have by hypothesis that P = 9 (Pi) and R implies 
6(P 2 A P 3 ... A Conds). Hence RAP implies 9(P 1 A P 2 A P 3 ... A Conds) 
which by (fT7|) implies 6{P'). Hence RAP implies A O(P'). We can 
summarize (3.8), together with its associated conditions, as the inference 



rule 



(Conds -> (Pi A P 2 A P 3 ...) = P') A 
R^9(P 2 AP z ...AConds) 

RA9(P 1 )=RA9(P') (3.9) 



The next step is to generalize ( |3.9|) by making explicit the concept of 
the "conjunctive context". We do this by splitting it into two inference 
rules, ( 3.10 ) and ( 3,11| ), as follows: 



(Conds -» (Pi A P 2 A P 3 ...) = P') A 

Context -> 9(P 2 A P 3 ... A Conds) 

Context -> (0(Pi) = 0(P')) (3.10) 

Context AQ^(P = P') 

Context -» (P AQ = P' AQ) (3.11) 



The proofs of ( p. 10 ) and ( |3.11| ) follow from that of (|3.9|). The two rules 



can be used recursively together to translate formulas composed using an 
arbitrary number of occurrences of the conjunction operator. In both rules, 
the formulas before the =>■ are the premises, and the formula after the con- 



clusion. ( 3.10 ) is the base case: it gives sufficient conditions for using ( p72| 



to translate Pi to P' . The other formula, ( 3.11| ), is the recursive case; it 



expresses translation of a conjunction in terms of translation of one of its 
conjuncts, adding the other conjunct to the conjunctive context as it does so. 
The advantage of splitting ( j3~l]| ) into ( 3.10 ) and ( |3.11|) is that it is then possi- 



ble to add rules for other logical operators, each of which passes around the 
conjunctive context; we will call rules of this kind translation- schemas. We 
now present some more translation-schemas, starting with those for quanti- 
fied expressions, (gjj) and ( jnf) express translation of a quantified form 



in terms of translation of its body. In each of them, 9 substitutes a set of 
unique constants for the x. 

Context -» (9(P) = 9(P')) 
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Context (3x.P = 3x.P') (3.12) 
Context -» (0(P) = 0(P')) 

Context -» (Vz.P = Vz.P') (3.13) 



Next, the schemas (fig) , (13151) , (gl(| and ( PI) express translations of 



disjunctions, negations and implications in terms of translations of their 
component sub-formulas. Note that the left-hand side is added to the context 
when translating the right-side side in ( |3.17 ), but not vice versa. 



Context -> (P = P') 

Context -> (P V Q = P' V Q) (3.14) 
Context -»■ (P = P') 

Context -> (-.P = -P') (3.15) 
Context -»■ (P = P') 

Context -> (P -> Q = P' ^ Q) (3.16) 
Context A P -> (Q = Q') 

Context ^ (P ^ Q = P ^ Q') (3.17) 



The proofs of ( 3.12| )-( |3.17| ) are straight-forward. 



(|3. 10| ) — ( 3.17 ) thus define a set of schemas which can be used to express 
translations of complex formulas built up with the connectives A, 3, V, V, -i 
and — > in terms of translations of their components. Together, they define 
a way in which "universal" equivalences can be used as truth-preserving 
conditional rewriting rules, licencing translation of one of the conjuncts on 
the left-hand side into the right-hand side in suitable conjunctive contexts. 

3.2.2 "Existential" equivalences 

We have so far only considered universal equivalences, i.e. equivalences of 
type fl3.2|) . As we have seen, the information used to determine when an 
universal equivalence is applicable is passed through the conjunctive con- 
text. For existential equivalences (equivalences of type ( |3.3| )), the problem 
is rather to make sure that they are used in contexts where the variables are 



48 



CHAPTER 3. AET 



appropriately quantified. We will basically adopt a minimal solution to this 
problem, encoded in the easily-proved translation schema 

3x.P 1 = P' 

0(3x.Pi) = 9(P') (3.18) 

where 9 is is one-to-one on x (i.e. it does not map distinct existential vari- 
ables in x into identical ones in 9{x)). At first glance, this seems terribly 
restrictive, since it virtually limits application of an existential equivalence 
E to sub-formulas that are syntactic variants of E's left-hand side. Things 
are actually rather better than they look, however, since it is possible to 
exploit the fact that 

3x3y.{Rf\P 1 ) 

is equivalent with 

3y.(R A 3s. Pi) 

if the x do not occur in R. This equivalence makes it possible to "move" 
existential quantifiers to the right place in the formula, so that they become 
associated with goals that are to be translated using existential equivalences, 
and in practice seems to provide all the flexibility needed. It is moreover 
possible to "move" the existential quantifiers "on demand" in a simple way 
which interacts cleanly with the rest of the AET translation process. The 



details are presented below in Section 3.2.4. First, however, we define a 
second way to use the equivalences - as normal Horn-clauses - which as we 
soon shall see is also essential to the translation process. 



3.2.3 Horn-clause readings of equivalences 

An equivalence of the form 

Vx.(Pi A P 2 A . . . = By.Qi A Q 2 A . . .) <- Conds 
implies the validity, for any k, of all Horn-clauses either of the form 
Vx.Vy.(P fc <- Qi A Q 2 A . . . A Conds) 

or 

\/x.{9(Q k ) <- Pi A P 2 A . . . A Conds) 
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where replaces the y with Skolem functions of the x. We will refer to these, 
respectively, as normal and backward Horn-clause readings of the equiva- 
lence. For example, the rule 

woman' (X) A employee' (X)) = 3HasCar.EMPL(X, w, HasCar) (3.19) 

produces two normal Horn-clause readings, 

woman' {X) <- EMPL(X, w, HasCar) (3.20) 

employee' (X) <- EMPL(X, w, HasCar) (3.21) 
and one backward Horn-clause reading, 

EMPL(X, w, skx (X)) <- woman' (X) A employee (X) (3.22) 

where sfci is a Skolem function. In the implementation, each equivalence is 
compiled in three different ways, to yield the normal Horn-clause, backward 
Horn-clause and equivalential readings. The Horn-clause readings are used 
to support proofs from the conjunctive context. We have experimented 
with using both kinds of Horn-clause; at present, though, only the normal 
Horn-clauses are used in the implemented system, for reasons discussed in 
Chapter [j| 

3.2.4 The abstract AET process 

We can now sketch out the basic translation process. The actual process 
of translation of a complex formula F is a series of single translation steps, 
each of which consists of the translation of an atomic constituent of F. A 
translation step contains the following sub-steps, with either Translate- 
universal, or Translate-existential being applied. 

Recurse: Descend through F using the translation-schemas, until an atomic 
sub-formula A is reached. During this process, a conjunctive context 
E has been accumulated in which conditions will be proved, and some 
bound variables will have been replaced by unique constants. Con- 
stants resulting from bound variables are specially marked if i) they 
come from existentially bound variables that occur only in A, and ii) 
the only connectives between A and the binding existential quantifier 
are conjunctions. We will refer to these as marked existential constants. 
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Translate-universal: Find a rule (H A R = B) <— C such that H unifies 
with A with m.g.u. 8. If it is then possible to prove 8(R A C), re- 
place A with 0(B). The leaves of the proof may include elements of 
the conjunctive context E, facts from the database, Horn-clauses from 
the linguistic domain theory T, or Horn-clause readings of conditional 
equivalences from T. 

Translate-existential: Find a rule 3x.H = B such that H unifies with A 
with m.g.u. 8. If all the elements of 8(x) are distinct marked existential 
constants (in the sense defined immediately above in the Recurse 
step), then replace A with 8(B). 

Simplify: if possible, apply simplifications to the resulting formula. 

When describing translation, we will often find it convenient, by analogy 
with the corresponding terminology for logic programming, to refer to A in 
the description above as the selected goal, H as the head of the rule used, 
and R AC (in the case of a universal rule) as its conditions. 

3.3 A simple example 

An example follows to illustrate how the AET process works. In the interests 
of expositional clarity we use a grossly over-simplified version of the actual 
CLARE domain rules. In particular, we will fail to distinguish between 
database objects and real-world objects, since our current focus is the AET 
process itself rather than the structure of the linguistic domain theory. We 
start with the sentence (S2), 

(S2) Do any women work on CLARE? 

which receives the LF 

3X3E .woman' (X) A workjon (E,X,clare) (3.23) 

( 3.23| ) has to be mapped to a query which accesses two database relations. 
The first is the employee relation 

EMPL(Empl, Sex, HasCar) 

where Empl represents employees, Sex can be w or m, and HasCar can be 
y or n. The second is the project-member relation 



PROJMEM(Empl, Project) 
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where Empl again represents the employee and Proj the project. The de- 
sired result is ( |3.24| ): 

3X3HasCar.EMPL(X, w, HasCar) A PRO J MEM (dare , X) (3.24) 

The most clearly non-trivial part is justifying the conversion between the lin- 
guistic relation woman' (X) and the database relation EMPL(X, w, _) Even 
in a very restricted context, it may well be incorrect to state that "woman" is 
equivalent to "employee classed as being of female sex" ; in the implemented 
PRM domain theory, it is definitely wrong, since both employees and payees 
are classified by sex. It is thus more correct to say that a tuple of type 
EMPL(X,w, _) is equivalent to the conjunction of two pieces of informa- 
tion: firstly that X is a woman, and secondly that she is an employee. This 
can be captured in the rule 

woman' (Person) A employee' (Person) = 
3HasCar.DB_EM PLOY EE(Per son, w, HasCar)) (3.25) 

In the left-to-right direction, the rule can be read procedurally as follows: 

woman (X) 

translates to 

3Y.EMPL(X, w, Y) 
in contexts where it is possible to prove 

employee' (X) 

For the rule to be of use in the present example, we must therefore provide 
a justification for employee' (X)^ holding in the context of the query. The 
simplest way to ensure that this is so is to provide a Horn-clause meaning 
postulate, 

employee' (X) <- PROJMEM(Project,X) (3.26) 

which encodes the fact that people listed in the database as project members 
are employees. 

Similarly, we will need an equivalence rule to convert between work-on' 
and PRO J MEM. Here the fact we want to state is that project-members 
are precisely people who work on projects, which we write as follows: we split 
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the equivalence into two formulas for the reasons explained at the beginning 
of Section p. 2.1 . 



work-on' (Event, Per son, Project) A project' (Project) = 

work-on -project 1 (Event, Person, Project) (3.27) 

BEvent.work-onjproject' (Event, Person, Project) = 

PROJMEM(Project, Person) (3.28) 

We will also make indirect use of a rule that states that projects are objects 
that can be found in the first field of a PRO J tuple, 

project' (Pro j) = 
3ProjNum3Start3End.PROJ(Proj, ProjNum, Start, End) (3.29) 

since this will allow us to infer (by looking in the database relation PRO, J) 
that the predicate project' holds of dare'. 

Three translation steps now produce the desired transformation. In each, 



the schema for existential quantification (3.12) and the schema for conjunc- 
tion ( p. 11| ) are used in turn to reduce to the base case of expanding an 
atom. Remember that existential quantification schema replaces variables 
with unique constants; when displaying the results of such a transformation, 
we will consistently write X* to symbolize the new constant associated with 
the variable X. 

The first translation step selects the atomic subformula of (|3.23|) 

work-on' (E, X, clare') 

which after replacement of bound variables by constants becomes 

workjon '(E*, X*, clare) 

The associated conjunctive context is {woman' (X*)}. Now the equiva- 
lence (|3 .27 ) can be used, taking the first conjunct on its LHS as the head; 



its conditions after unification with the selected atom are the remaining 
conjuncts on the LHS, i.e. 

project' (clare') 

The normal Horn-clause reading of ( |3.29| ) can be used to reduce the conditons 
to 

3ProjNum3Start3End.PROJ(clare', ProjNum, Start, End) 
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which can be proved directly by a call to the database relation PROJ . 
Since the conditions have been proved to hold, work_on'(E,X,clare') can 
be replaced by work_onjproject(E, X,clare') in (|3.23| ), yielding the result 

3X3E. woman' (X) A work-on -project' (E , X , dare') (3.30) 



The second translation step now uses ( 3.28j ) to translate the second conjunct 



of ( p. 30 ). ( 3.28Q is an existential equivalence, so there are no conjunctive 



conditions; it is on the other hand necessary to check that the variables are 



appropriately bound. The first variable in the LHS of (3.28) is existentially 
bound, so the first variable in the selected goal must also be existentially 
bound by a quantifier which is seperated from the goal only by conjunctions. 
Recall that these conditions are required to be able to rewrite ( 3.30 ) into 
the form 

3Xwoman (X) A (3E.work-on..project'(E,X,clare')) (3.3f) 



As this is possible, work_on-projed(E, X,clare') in ( 3.30|) can be replaced 
by the body of ( 3.28j ), giving 



3X3E. woman' (X) A PRO J MEM (dare , X) (3.32) 

and as quantification over E has become vacuous, ( p.32| ) can be simplified 
to 

3X.woman'(X) A PRO J MEM (dare' , X) (3.33) 
We are now in a position to be able to translate the first conjunct of ( |3.33| ), 

woman' (X) 

After replacing bound variables by constants, this becomes 

woman (X*) 

and the conjunctive context is {PRO J MEM (dare' , X*)}. woman' (X*) 
unifies with the first conjunct on the left-hand side of the equivalence ( |3.25| ), 
making its conditions employee' (X*). Using the Horn-clause meaning pos- 



tulate (3.26), the conditions can be reduced to PROJMEM(Project,X*). 
Note that X* in this formula is a constant, while Project is a variable. This 
new goal can be proved directly from the conjunctive context, instantiating 



Project to dare'. So the selected goal can be replaced in ( 3.33 ) by the body 
of ( p.25| ), yielding the final result 

3X3HasCar.EMPL(X, w, HasCar) A PRO J MEM (dare , X) (3.34) 
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3.4 Translating higher-order formulas 

It is possible to extend AET without much trouble to provide an adequate 
coverage of the higher-order constructs that commonly occur in the context 
database querying: the most important are those for counting, summing and 
ordering. We will represent these respectively by the operators count, sum 
and order, with the following syntax and semantics: 

count(N, XX.P(X)) 

holds if there are precisely N values of A such that P(A) holds; 

sum(S, XX.P(X)) 

holds if all the objects A of which P(A) holds are summable quantities, and 
S is their sum; and 

order (Selected, XX.XD.P{X, D), Ordering) 

holds if Ordering is an ordering relation, D max is the maximal D under the 
relation Ordering such that P(X, D) holds for some X, and Selected is such 
an X. 

Expressions formed using these operators can be translated by translat- 
ing their bodies, replacing the bound variables by unique constants as in the 
schemas for universal and existential quantifiers shown earlier. For example, 
the schema for count is 

Context -> (0(P) = 9(P')) 

Context -» {count{N, XX. P) = count{N, XX.P')) (3.35) 

where 6 replaces X with a unique constant. 

As can be seen, the conjunctive context is passed into the body of the 
higher-order form and is available for rules used to translate it. What is more 
interesting to consider is the extent to which the material in the bodies of 
these higher-order forms can be "exported" out to add to the context of goals 
conjoined with higher-order forms; this is frequently desirable. The solution 
we have adopted is to assume that the A-bound properties appearing in the 
bodies of sum, count and order forms always have non-empty extensions, in 
other words that the following hold: 



count{N,XX.P{X)) -» 3X 1 .P(X 1 ) (3.36) 



3.5. ABDUCTIVE TRANSLATION 



55 



sum(N,XX.P(X)) -» 3Xi.P(Xi) (3.37) 

order (Selected, \X.\D.P(X, D), Ordering) — > 

3D 1 .P(Selected,D 1 ) (3.38) 

This means, for instance, that given a formula of type 

C Acount(iV, AXP(X)) 

it is permissible to assume 3Y.P(Y) when translating C. A special case is 
presented by the order operator; as can be seen from (3.38), it is possible to 



make a stronger assumption, substituting the maximal element (rather than 
an existentially quantified one) in the outermost lambda-binding. 

3.5 Abductive translation 

We now put the "A" into "AET", and describe how the basic framework 
can be extended further to allow abductive translation. There are essen- 
tially two problems. Firstly, we want if necessary to be able to make ab- 
ductive assumptions when performing the Translate-universal step of the 



AET process described Section 3.2.4: in other words, we want to be able to 
define situations where some of the information required to license a trans- 
lation step is assumed rather than proved. Goals will be classed as potential 
abductive assumptions if they ought to be assumed true when there is no 
specific evidence to the contrary. This brings us to our second requirement: 
that we should be able to define ways in which an abductive assumption is 
contradicted by its context of occurrence. 

These two functionalities are achieved as follows. We include declarations 
of the form 

assumable (Goal , Cost , Just if i cat ion , Type , Cond) 

where Goal and Cond are atomic formulas, Cost is a non-negative integer, 
Justification is a unique tag that names the assumption, and Type is the 



assumption- type (cf Section p.4.l[) . The intended semantics are that Goal 
may be assumed at cost Cost in an environment where Cond holds. The "jus- 
tification" can be used to identify the assumption to the user. If an abductive 
assumption A is made while translating the goal G, it is saved together G's 
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associated conjunctive context Context. Assumptions are considered to be 
inconsistent if 

T U Context -> ->A 



holds, where T is the linguistic domain theory. The implemented system 
has so far only a fairly primitive ability to find proofs of negated goals (cf 



Sections 5.1.3 and 4 



Examples of how assumption declarations are used will be presented later 
in Sections |4.5| and 4.7. 



3.6 Simplification 

AET, like many systems based on the idea of rewriting, tends to suffer from 
the problem that expressions can rapidly grow in size as they pass through 
successive stages of translation. The standard solution to the problem is to 
include a simplifies a module which takes the output from a translation stage 
and attempts to reduce it to a more compact form (cf e.g. (Williams 1991)). 
This section will describe CLARE's simplifier. Although the simplifier's 
primary use is in conjunction with the translator, it has turned out to provide 
a functionality that several other parts of the system utilise. In section p. 6. 3 



we describe how the simplifier is used in the processing of assertions; here, 
the problem is to take the conjunction of the TRL representations of several 
assertions, and combine them into a compact form. 

The simplifier consists of two main pieces. The first, described in sec- 
tion 3.6. 1| , is a collection of standard logical rewriting techniques, none of 



which use inference, that have the common function of reducing expressions 
to a canonical form. Simplification can also be carried out by using the 
inference-based equivalential translation methods described earlier in this 
chapter, in which inference justifies the replacement of sub-expressions by 
other forms, the equivalence of which is implied by the context. This second 
type of simplification is described in section [3.6.2 . 



3.6.1 Non-inferential simplification 

The non-inferential simplification module consists of the set of rewriting 
methods listed below. Most of them are fairly obvious. We present the 
methods in the order in which they are applied by the system. 
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Moving existential quantifiers outwards 

This method consists of two kinds of rewriting rule. The first simplifies an 
expression built out of conjunction and existential quantification operators 
into an equivalent form with a single existential operator on the outside 
binding all the variables (it has proven convenient to slightly extend standard 
predicate calculus notation by allowing a quantifier to bind an arbitrary 
number of variables) . Thus for example 

3x.p(x) A 3y.q(y) 

will get rewritten to 

3x,y.p{x) Aq(y) 

The other rewriting rule is applied when an existentially quantified form 
occurs on the LHS of an implication; in this case, the existentially quan- 
tified variables are moved upwards to become universally quantified with 
wide scope over the implication. The justification for this manoeuvre is the 
equivalence 

((3x.P) -> Q)) = Vx.(P -» Q) 

which is easily proved. The result of recursively applying the two rules is 
to give existential quantifiers as wide scope as possible, if necessary turning 
them into universals on the way. 

Simplification of equalities 

The next simplification step removes equalities from the expression when this 
is possible. The basic equivalences that licence this type of simplification are 
the following: 

(3x.3y.P A (x = y)) = (3x.P[y/x\) 
(\/x.3y.P A (x = y)) = {Mx.P[y/x}) 

and 

(3y.PA(y = a)) = P[y/a] 

where a is a constant. The methods are implemented by recursively de- 
scending through the expression to find equality sub- forms, and in suitable 
cases unifying together their two arguments, replacing the equality with an 
occurrence of the identically true predicate. After this, a second pass re- 
moves the occurrences of true and the vacuous and repeated quantifications 
introduced. 
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If the expression contains an equality whose arguments consist of two 
non-unifiable constants Arg\ and Arg2, its value can be known to be identi- 
cally false (assuming non-identity of reference of distinct constants) . In this 
case, the simplifier replaces the equality with the form 

mismatch(Argi, Arg2) 

Subsequent behaviour depends on the nature of the expression being ma- 
nipulated. If it is a question, the mismatch form is later replaced with 
an occurrence of the identically false predicate, which will generally lead 
to a "No" answer being produced. If the expression however represents an 
assertion, the mismatch normally represents a presupposition failure. In 
this case, the interface handler will inform the user that the expression was 
translated to an identically false form due to the occurrence of the mismatch, 
and attempt to print the incompatible arguments in an informative way (cf. 
Section 2.5.3| ) . 



Simplification of ground sub-expressions 

The final type of simplification involves ground sub-expressions, that is to 
say sub-expressions containing no variables. Since these can be assigned a 
truth- value irrespective of their context, the expression can be simplified by 
computing it and replacing by an occurrence of either true or false. At 
present, the method is restricted in two ways: ground sub-expressions are 
only replaced if their predicates are declared to be executable relations (cf. 



section 2.4.2); also, only true ground expressions are substituted. 



3.6.2 Inferential simplification 

We will now consider methods that use equivalential translation to carry out 



simplification; the notion of conjunctive context, defined in section 3.2.1, will 
play a key role. We can immediately describe one way to achieve this end. 
Suppose that F is a formula containing an occurrence of the subformula F', 
and suppose further that F' is implied by its conjunctive context. It follows 
that replacing F' with true in F will result in a formula equivalent with F. 
This gives a method can remove duplicated conjuncts and the like, and also 
perform less obvious simplifications. To take a simple example, consider the 
formula 

P AQ -> P AR 
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The conjunctive context of the second occurrence of P contains P, so the 
formula can be simplified to 

P AQ -> R 

A slightly more complex example is provided by the formula 

P -> Q AR 

where we are also told that Q can be derived from P. Then as we know that 
P is in Q's conjunctive context, it is possible to remove Q and simplify to 

P^R 

A similar, but more refined, form of simplification can also be performed, 
which exploits functional relationships between arguments in predicates. We 
start by re-examining our example (SI) from the beginning of chapter [2|, 
reproduced here for convenience. 

(SI) Show all payments made to BT during 1990. 

In section [4.9| , we will see that, when the example is processed by the im- 
plemented CLARE system, the logical form originally derived from (SI) 
is 

f orall ( [Trans] , 

impl (x ( [Agnt , Ev] , 

and (payment 1 (Trans) , 

and (make2(Ev, Agnt , Trans ,payeel#bt) , 
duringl(Ev,yearl#1990)))) , 
x( [ShowEv] , 

and(showl (ShowEv, clare , Trans) , 
bef orel (<Now> , ShowEv) ) ) ) ) 

After a few translation steps, the resulting formula contains three separate 
instances of the transaction relation, one from each of the original linguistic 
predicates payment 1, make2 and duringl. Assuming that the arguments of 
the transaction relation are 

transact ion (Transact ion , Payer , Date , Payee , Amount ) 



payment 1 (Payment) expands, roughly speaking, to 
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transaction (Payment ,_,_,_,_) 

make2 (Event, Agent, Payment, Payee) expands to 

transaction (Payment /Event , Agent , _ , Payee , _) 

(the Payment and Event arguments map into the same variable). Finally, 
during! (Payment , Interval) expands to 

and (transact ion (Payment ,_ ,Date , _ , _) , 
time_during(Date , Interval) ) 

The database query will conjoin all three instances together. It is clearly 
preferable, if possible, to merge them instead, yielding a composite predica- 
tion 

transact ion (Payment /Event , Agent , Date , Payee , _) 

The information that licences this step as a valid simplification is that 
transaction is a function from its first argument (the payment) to the 
remaining ones (the agent, the date, the payee and the amount); in other 
words, a given payment is made by a unique agent, on a unique date, to a 
unique payee, for a unique amount. The system allows the information to 
be entered as a "function" meaning postulate in the form 

f unct ion (transact ion (Transact ion , Payer , Date , Payee , Amount) , 
[Transaction] -> [Payer, Date, Payee, Amount] ) 

which is treated as a concise notation for the conditional equivalence 

transaction(Trans, Payer', Date 1 , Payee', Amount') — > 
(transaction(Trans, Payer, Date, Payee, Amount) = 
Payer = Payer' A Date = Date' A 
Payee = Payee' A Amount = Amount') (3.39) 

It is thus possible to view "merging" simplification of this kind as just an- 
other instance of equivalential translation. In the current version of the 
system, the transformation process operates in a cycle, alternating normal 
translation followed by simplification using the same basic interpreter; sim- 
plification consists of functional "merging" followed by reduction of equalities 
where this is applicable. 
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3.6.3 Simplification for processing assertions 

The simplification process plays an important role in the processing of as- 
sertions (cf Section [2.5.3 ), Consider, for example, what would happen to the 
pair of sentences (Assertionl) and (Assertion2) without simplification: 

(Assertionl) Clara is an employee who has a car. 

(Assertion2) Clara is a woman. 



Assuming a suitable extension of the axioms used in Section 3.3 above, As- 
sertionl translates into the database form 



3A.EMPL(clara,A,y) 

(Recall that the second field in the EM PL relation indicates sex, and the 
third whether or not the employee has a company car). This can then be 
put into Horn-clause form as 

EMPL(clara!,ski,y) 

(where ski is a Skolem constant) to make it accessible to inferencing op- 
erations. Since Clara is now known to be an employee, Assertion2 will 
eventually translate into the unit clause 

EMPL(clara,w,sk 2 ) 

with sk 2 a second Skolem constant. The two clauses produced would contain 
all the information entered, but they could not be entered into a relational 
database as they stand; a normal database has no interpretation for the 
Skolem constants ski and sk 2 . 

However, it is possible to use function information to merge the two 
clauses into a single record. The trick is to arrange things so that the sys- 
tem can when necessary recover the existentially quantified form from the 
Skolemized one; assertions which contain Skolem constants are kept together 
in a cache called the logical discourse context. Simplification of assertions 
then proceeds according to the following sequence of steps: 

1. Retrieve all assertions from the logical discourse context cache. 

2. Construct a formula A, which is their logical conjunction. 
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3. Let Aq be A, and let {ski ■ ■ ■ sk n } be the Skolem constants in A. 
For i = 1 . . . n, let X{ be a new variable, and let Ai be the formula 
3xi.Ai_i[ski/xi\, i.e. the result of replacing ski with Xj and quantify- 
ing existentially over it. 

4. Perform normal function merging on A n , and call the result A'. 

5. Convert A' into Horn-clause form, and replace the result in the logical 
discourse context cache. 

In the example above, this works as follows. After (Assertionl) and (As- 
sertion) have been processed, the logical discourse context contains the 
clauses 

EMPL(clara',ski,y) 
EMPL(clara',w,sk 2 ) 
A = Aq is then the formula 

EMPL(clara, ski,y) A EMPL(clara! , w, sk 2 ) 

and A 2 is 

3X 1 ,X 2 .EMPL(clara, X u y) A EMPL{clara', w, X 2 ) 

If EM PL is declared functional on its first argument, the second conjunct 
can be reduced to two equalities, giving the formula 

3X 1 ,X 2 .EMPL(clara',X 1 ,y)AX 1 = w A y = X 2 

which finally simplifies to A', 

EMPL(clara', w, y) 

a record without Skolem constants, which can be added to a normal rela- 
tional database. 

3.7 The "Doctor on Board" problem 

One of the best-known problems in the area of logic-based natural-language 
database interfacing is posed by so-called "Doctor on Board" queries (Per- 
rault and Grosz, 1988). These are the standard examples of the problems 
that arise when existentially quantified variables in the logical form fail to 
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correspond to any quantified variable in the final evaluable expression. The 
original example came from a naval information database, in which the main 
relation contained information about the position and other attributes of a 
set of ships; one field was set to y if there was a doctor on board the ship in 
question. Now consider the three queries (DOB1 3) below: 

(DOB1) Is there a doctor on board ship FOO? 

(DOB2) Who is the doctor on board ship FOO? 

(DOB3) Is there a doctor within 500 miles of ship FOO? 

It is clear that a query like (DOB1) should be answerable; it is equally 
clear that a query like (DOB2) should not. Most interestingly, queries like 
(DOB3) should also be answerable, since the position of a doctor can be 
assumed to be the same as the position of his ship. 

In this section, we will sketch out a treatment of the "Doctor on board" 
problem within the AET framework; we will abstract away as many of the 
details as possible. In accordance with the ideas described in Sections [2.5.1 



and 2.5.2, we begin by assigning the orig inal logical forms (|3~4C|)-(|3^) to 



DOB1 3: 

3X.doctor'(X) A on_board'(X, foo') (3.40) 

VX. (doctor' (X) Aon_board'(X,foo') -> 

display ed-in_future(X)) (3-41) 

3X.doctor'(X) A within' (X, foo', 500) (3.42) 

We will assume that the basic database predicate we are mapping to is 

SHIP(ShipId, Position, DoB) 

where Position is a position expressed according to some suitable co-ordinate 
system, and DoB has the value y if there is a doctor on board the ship, n 
otherwise. We will require SHIP to be functional on its first argument (i.e. 
the field Shipld will be a primary key). There will also be two evaluable 
predicate 

dist(Position\, Position, Distance) 
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and 

X < Y 

The first of these computes the distance (as a number) between two posi- 
tions, according some suitable distance metric; the second is the standard 
arithmetic inequality relation. 

We are now in a position to write down the axioms we will need. The 
first three define the relationship between the word-sense predicates ship', 
doctor' and onJboard', and the database predicate SHIP: 

ship'(S) = 3Pos3DoB.SHIP(S, Pos, DoB) (3.43) 

doctor' '(D) A onJjoard! (D, S) = 

doctor _onJjoard(D , S) (3.44) 

3D. doctor _on _board(D, S) = 

3Pos.SHIP(S,Pos,y) (3.45) 

Axiom ( |3.46| ) defines the semantics of the word-sense predicate within' in 
terms of positions and distances: 

within' (X i, X2, Radius) = 
pos(X 1 ,P 1 ) Apos(X 2 ,P 2 ) Adist(P 1 ,P 2 ,D) AD < Radius (3.46) 

The last two axioms translate the intermediate predicate pos; two rules are 
provided, one for positions of ships and the other for positions of doctors. 

ship'(S) — > 

(pos(S, P) = 3DoB.SHIP{S, P, DoB)) (3.47) 
doctor' (D) -> 

(pos(D, P) = (3S.ship'(S) A on_board{D, S) A pos{S, P))) (3.48) 

Finally, we will assume that the database shows foo' to be a ship, i.e. that 
there is a SHIP record whose first field contains an instance of foo'. 

Let us now first consider how the axioms we have just presented can be 
used to translate the logical form corresponding to the query (DOB1). The 
original LF is 



3X.doctor'{X) A on.board'(X, foo') 



(3.49) 
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Using the existential and conjunction translation schemas in the way de- 
scribed in Section 3^3, we choose as the selected goal the second conjunct: 
after replacement of bound variables by constants, this is 

onJ>oard'(X*, foo') 

and the conjunctive context is 

{doctor' '(X*)} 

We use the equivalence ( 3.44[ ) to translate; the conditions can be proved 
directly from the conjunctive context, and the result after substitution is: 

3X. doctor' (X) A doctor _onJboard(X, foo') (3.50) 

The first conjunct of ( 3,50| ) can be simplified away (see section 3.6.2[ ); since 
one of the normal Horn-clause readings of ( |3.44 ) is 

doctor' (X) <— doctor _onJ>oard(X, S) (3.51) 

we have that 

doctor' (X) 
is implied by its conjunctive context 

{doctor _onJ)oard{X , foo')} 

and can thus be removed. This reduces ( |3,50D to 

3X. doctor _onJ)oard(X, foo ) (3.52) 

Since X is existentially quantified and only occurs in the atomic sub-formula 

doctor _onJ)oard(X , foo') 

it is now possible to apply ( 3.45j ), to translate to the final evaluable form 

3Pos.SHIP(foo',Pos,y) (3.53) 

We next examine (DOB2), which receives the initial LF 

V X. (doctor' (X) Aon_board'(X,foo') -> 

display ed-in_future(X)) (3.54) 
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By a similar sequence of steps to those used for (DOB1) above, ( 3.54 ) can 
be translated as far as the formula 

3X. doctor _onJ)oard(X, foo ) — ► displayed-in_future(X) (3.55) 

In contrast to the previous case, however, it is impossible to translate ( |3.55[ ) 
any further; ( 3.45 ) is this time not applicable, as X is bound by a universal 
quantifier rather than an existential, and moreover occurs on the RHS as 
well. 

We finally turn to (DOB3), with initial LF 

3X.doctor'(X) A within' (X, foo', 500) (3.56) 

Omitting the details, we can first use (|3.46| ) to translate ( |3.56|) into 

3X, P d , P foo , D.doctor'(X) A pos(X, P d ) A pos(foo', P foo ) A 

dist(P d , P foo , D) A D < 500 (3.57) 

Since the goal doctor'(X*) is a member of the conjunctive context of the 
second conjunct, pos(X, P d ), it is possible to translate it using (|3.4§| ), giving 

3X, P d , Pfoo, S, D. doctor' {X) A ship'(S) A onl>oard(X, S) A 

pos{S, P d ) A pos(foo', P^o) A dist{P d , P foo , D) A D < 500 (3.58) 

By the same methods as those used for (DOB1) above, we can then translate 
the conjunct oruboard(X, S), and simplify away the conjuncts doctor' '(X) 
and ship'(S), yielding 

3X, P d , P s ,P f oo, S, D.SHIP(S, P s , y) A pos(S, P d ) A 

pos(foo', Pfoo) A dist{P d , Pfoo, D)AD< 500 (3.59) 

We now want to translate the two pos conjuncts, using ( |3.47| ). In the first 
case, the selected atom is 

pos(S*,P d *) 
The conditions deriving from ( |3.47 ) are 

ship'(S*) 

which can be proved using the normal Horn-clause reading of (|3.43j ), i.e. 
ship'(X) <- 3P,DoB.SHIP{X,P,DoB) 
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The atom 

SHIP(S*,P s *,y) 
can be proved from the conjunctive context. The result is 

3X, P d , P s , DoB, P foo , S, D.SHIP(S, P s ,y) A SHIP(S, P d , DoB) A 

pos{foo, P foo ) A dist(P d , P f o , D) A D < 500 (3.60) 

Since SHIP is functional on its first argument it is possible to use functional 
merging (cf. Section 3.6.2) to merge the first and second conjuncts, giving 



3X, P s ,Pf 00 , S, D. A SHIP(S, P s ,y)A 
pos(foo', Pfoo) A dist(P s ,P foo , D) A D < 500 (3.61) 

Lastly, the remaining pos conjunct can be translated, using the equiva- 
lence ( |3.47] ), the normal Horn-clause reading of ( p. 43 ) and the database 
relation SHIP. This allows 

pos(foo',Pf 00 ) 

to be replaced with 

3DoBf 00 .SHIP(foo', P^o, DoBfoo) 

giving the final evaluable form 

3X, P s ,Pf 00 , DoB^o, S, D.SHIP(S, P s ,y) A 
SHIP(foo', P^o, DoB^) A 
dist(P s , P^o, D) A D < 500 (3.62) 

3.8 The translation engine 

This section sketches the CLARE translation engine, the existing Prolog im- 



plementation of the abstract AET process described earlier in Section 3.2.4. 
The structure of the translation engine is fairly similar to that of a Prolog 
meta-interpreter. There is a main predicate, 



translate (+In , -Out , +Context , +MarkedConstants , +Ain , -Aout ) 
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The intended semantics are that Out is a translation of In when it occurs 
with conjunctive context Context, and the variables in the list Marked are 
constants deriving from existentially bound variables, that are "specially 



marked" in the sense described in Section 3.2.4; Ain-Aout is a difference list 
holding the abductive assumptions made while performing the translation. 
There is one or more translation clause for each logical operator Op, each of 



which encodes an appropriate "translation schema" for Op (cf. Section 3.2.1). 

The clause encoding the base case is applied when the main functor of 
In is a predicate symbol, rather than a logical operator. Here, an attempt is 
made to find an equivalence that can be used to translate In. Equivalences 
are stored in the compiled form 

equiv (Head , Conds , ExVars , Body , Group) 

where 

• Head is a potential "head" of the rule, i.e. an atomic goal on its LHS; 

• for universal rules, Conds are the remaining LHS conjuncts; 

• for existential rules, ExVars are the existentially quantified LHS vari- 
ables; 

• Body is the RHS, and 

• Group is an atom that associates the rule with a named "rule-group" . 

Prolog variables are used to represent both universal and existential variables 
in the rule. The last argument, Group, also demands some explanation; it is 
frequently useful, for modularity reasons, to be able to divide equivalences 
into distinct named groups. A declaration is also supplied that arranges the 
groups in a linear sequence Group\...Group n . Translation is first carried out 
as far as possible using only the rules from Groupi; then again using only 
the rules from Groups and so on. 

When trying to apply either a universal or an atomic rule to translate 
an atomic goal, the first step is to unify Head with In, which consequently 
instantiates Conds, ExVars and Body as well. Behaviour now diverges de- 
pending on whether the rule is universal or existential: 

• If the rule is universal, an attempt is made to prove Conds in the cur- 
rent conjunctive context; this in effect consists of sending the formula 



impl (Context , Conds) 
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and the current list of abductive assumptions Ain to the inference 
component (cf. Chapter ||). If a proof can be found, the call returns 
with a set of bindings for the free variables in Conds and an updated 
list of abductive assumptions Aout. 

• If the rule is existential, then the instantiated list ExVars from the rule 
and the list MarkedConstants from the original call to translate are 
passed to the predicate check_equiv_exvars/2, which succeeds if the 
members of ExVars are distinct members of MarkedConstants. 

3.9 Debugging equivalential theories 

To be practically useful, a programming language normally has to support 
some kind of interactive debugging tool. It has proved simple to build such 
a tool on top of the translation engine described in the last section; the 
functionality it offers is similar to that provided by the standard Prolog 
"Byrd-box" debugger. This has been enough to make it feasible to construct 
and debug large equivalential linguistic domain theories, containing several 
hundred equivalences and Horn-clauses. 

The top-level commands available to the user are similar to those in the 
normal Byrd-box debugger, and are summarized below: 

aet_debug_init 

Initializes AET debugger. It is then possible to use the other commands. 
aet_trace 

Switches on the AET debugger, in "trace" mode. 
aet_debug 

Switches on the AET debugger, in "debug" mode. 

aet_nodebug 
Switches off the AET debugger. 

aet_spy (+PredSpec ,+Mode) 

Puts an AET spypoint of type Mode on PredSpec. Mode must be either 
translation or inference. PredSpec must be of the form F/N. 
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aet_nospy (+PredSpec , +Mode) 

Removes an AET spypoint of type Mode on PredSpec. Mode must be either 
translation or inference. PredSpec must be of the form F/N. 

aet_nospyall 

Removes all AET spypoints. 

The AET debugger is implemented on top of the normal Quintus Prolog 
debugger, using the Quintus Prolog "advice" package. In view of the ex- 
tremely implementation-dependednt nature of the debugger, we will confine 
our description to a very brief sketch. The basic idea is to put normal spy- 
points on the central predicates (in particular translate and prove) that 
implement the translation and reasoning engines. "Advice" is added at all 
four ports of these key predicates, which checks the arguments passed to the 
predicate, the defined AET spypoints and the current mode, and if necessary 
switches the associated spypoint on or off. A special "portray" predicate is 
employed to format the predicate calls shown by the normal Quintus debug- 
ger in an easily readable way. Thus for example a completed call to the base 
case of translate is formatted as illustrated below: 

Translating atomic sub-formula 

<InFormula> 

<Result> 

Assumptions made: <Assumptions> 

where <InFormula>, <Result> and <Assumptions> are formatted represen- 
tations of the input and output of the translation, and the abductive assump- 
tions needed to perform it. Similarly, a completed attempt by the inference 
component to prove a goal is formatted as 

Prove (<CostIn> units in, <CostOut> units out) : 
<Formula> 

Assumptions made: <Assumptions> 

where <Formula> and <Assumptions> are the formula that has been suc- 
cessfully proved and the abductive assumptions used to prove it, <CostIn> 
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was the number of cost units available before the goal was attempted (cf 
Section 5.2), and <CostOut> was the number of cost units left afterwards. 
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Chapter 4 

Linguistic Domain Theories 



4.1 Introduction 

From the examples presented in the previous chapter, the reader will already 
have gained some impression of what a linguistic domain theory looks like. 
In this chapter, we will consider the subject in more detail. We first describe 
the various types of information that compose an LDT: equivalences, Horn- 
clauses, declarations of functional relationships and assumption declarations. 
The rest of the chapter describes the LDT for the PRM domain, which we 
will use as a generic example. 

There are four main kinds of information in the PRM LDT. The greater 
part of the theory is composed of conditional equivalences, which have al- 
ready been discussed at length in chapter |2| In this chapter, it will be 
convenient to allow equivalences to be written in the concrete TRL notation 
illustrated by the following example (cf also Appendix |B|) 

exists ( [Event] , 

and(work_onl (Event .Person, Project) , 
projectl (Project) ) ) <-> 
works_on_pro j ect (Event , Pro j ect , Person) 

Apart from the conditional equivalences, there are Horn-clause formulas, 
declarations of functional relationships between arguments of predicates, and 
declarations of what assumptions are permissible. We will first review each 
of these briefly; later on in the chapter, we explain more exactly how they 
fit into the LDT. 

Horn-clauses Certain relationships in the PRM LDT are inherently ones 
of implication rather than equivalence; in these cases, Horn-clauses, 
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rather than equivalences, are appropriate. For example, it is necessary 
to capture the fact that everyone who books time to a project is an 
employee. This cannot easily be made into an equivalence, since be- 
ing an employee does not directly imply that one books time to any 
particular project. Instead, we use the Horn-clause 

employee_Worker (Person) <- 

booking_to_pro j ect (Event , Person , Pro j , Hours , Date) 

Functional relationships Many relations have the property of being func- 
tional on some subset of their arguments; that is to say, selecting a 
particular given value for that subset determines a unique value for 
the remaining arguments. In practice, the most important case is that 
of primary key fields in database predicates. Functional relationships 
are defined by declarations of the form 

f unction(<Template> , <FunctionalArgs> -> <RemainingArgs>) 

In all the examples occurring in the PRM LDT, <FunctionalArgs> is 
a list consisting of a single argument. For example, the first argument 
of the TRANS relation is an identifier that functions as a primary key: 
this is captured by the declaration 

function (TRANS (Transld , ChequeNum , Date , Payee , Acct , Amount) , 
[Transld] -> [ChequeNum, Date , Payee , Acct .Amount] ) 

Assumption declarations Assumption declarations are used to control 
the abductive proof mechanism: it is only permissible to make an 
abductive assumption when this is explicitly licenced by an assumption 
declaration. An assumption declaration has the general form 

assumable (<Goal> , <Cost> , < Just if ication> , <Type> , <Conds>) 

The intended semantics are that <Goal> may be assumed at cost 
<Cost> in an environment where <Conds> hold. <Type> can be either 
specialization, limitation or approximation; this is explained 



further in section 2.4.1. < Justif ication> is a tag which can be used 
to identify instances of use of this declaration. Assumption declara- 
tions are mainly used in the PRM LDT to deal with the problem of 
"contingent completeness" of information. Examples can be found in 



Sections 4.5 and 4.7 



4.2. OVERVIEW OF THE EXAMPLE LDT 



75 



The rest of the chapter will explain in detail how these various kinds of 
information can be used to build up an LDT; we will focus on the specific 
PRM domain for lack of other large-scale examples, but we believe that 
many of the principles would carry over to other relational databases. 



4.2 Overview of the example LDT 

This section gives an overview of how the LDT for the PRM domain is 
structured. The PRM relational database is based on a real SRI projects 
and payments database; the LDT contains about 300 equivalences, 70 Horn 
clauses, 45 declarations of functional relationships, and 25 assumption dec- 
larations. 

It will be easiest to start by describing the various types of predicates 
used in the PRM domain's LDT. At one end are the linguistic predicates, 
mostly corresponding to word-senses; the names of these will be written 
in the form <LowerCaseSurf aceForm><Number> e.g. chequel, projectl, 
make2, onl, etc. At the other end, we have the predicates meaningful to the 
database. As explained in Section p. 4. 2 , these are of three kinds. 



Firstly, we have the database predicates themselves, which directly cor- 
respond to the database relations. We describe these in more detail im- 
mediately below. Secondly, we have arithmetical relation predicates, which 
define the permissible arithmetical operations that can be carried out on 
database objects. The LDT contains predicates corresponding to addition 
and subtraction, inequality between numbers, and temporal precedence be- 
tween representations of dates. Thirdly, we have the single executable pred- 
icate, instances of which the system can cause to hold in the world. The 
executable predicate is 

execute_in_f uture (Action) 

which holds if Tuple is a term representing an action which the system will 
perform at some future time. The type of action we will be most interested is 
the displaying of a list of database objects, which we write display (List) . 

We now return to consider the database relations, the names of which 
will be written entirely in upper case. We will refer to the following specific 
predicates: 

TRANS (Transld , Chequeld , Date , Payeeld , AccNum , Amt ) 

Non-payroll payments made by SRI Cambridge between 17/8/89 and 1/4/91. 
For each record, the transaction ID is Transld and cheque ID is Chequeld: 
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if Amt is positive, SRI paid the payee with name Payeeld the quantity Amt 
in pounds sterling on day Date, charging it to account AccNum. Records 
with negative Amt turned out to represent an abuse of the database system 
to record reimbursements of small debts to petty cash; this is characteristic 
of the sort of arbitrary condition that can easily apply in a real database. 

PROJECT (Name , Pro j ectNum , Start , End) 

Projects at SRI Cambridge. The project's name is Name and its account 
number is Pro j ectNum; the start date is Start and the end date is End. 

PAYEE (Payeeld , Type) 

Payees in listed transactions, classified by the field Type as being men (m), 
women (w), companies (c), universities (u) or others (o). 

EMPLOYEE (Name , Sex , HasCar) 

Employees at SRI Cambridge, classified by their sex (m or w) and whether 
or not they have a company car (y or ). 

TIMESHEET (Employeeld , Time , Date , Pro j ect ) 

Timesheet entries for the periods that had been entered when the database 
was compiled (these periods turned out to be project-dependent). The fields 
give in order the employee ID for the person booking the time, the number of 
hours booked, the date for which time was booked, and the account number 
charged to. 

To sum up, we have on one hand the linguistic predicates, which are 
directly related to language, and on the other the database, arithmetic re- 
lation and executable predicates, which are directly related to the database. 
Between these, it has proved convenient to define a number of other "in- 
termediate" predicates. There are in particular two specific types of inter- 
mediate predicates, which we will shortly describe, that play a major rule 
in the LDT; we call these conceptual predicates and attribute predicates. 
Translation, in the direction language to database, proceeds very roughly 
as follows. Linguistic predicates are translated into a mixture of conceptual 
and attribute predicates. The attribute predicates are then translated into 
conceptual predicates; finally, the conceptual predicates are tranlated into 
database predicates. 

The rest of the chapter will make this thumbnail sketch more explicit. In 



Section 4.2.1 , we begin by defining the types of terms used in the theory: in 
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particular, we consider the relationship between terms representing names 



and terms representing the objects referred to by the names. Sections 4.2.2 



and 4.2.3| describe conceptual and attribute predicates. We will then have 
presented enough definitions to be able to describe the structure of the LDT 
in detail. The LDT's axioms are stratified into three distinct groups, listed 
in order of increasing specificity: this reflects the basic strategy of translat- 
ing the original logical form predicates into predicates which are increasingly 
closer to the database. We refer to the groups as general, domain- specific 
and database-specific, and describe them in turn in Sections 4.3, 4.4 and [4.5| . 
The next three sections describe particular types of information in the LDT. 
Section 14.61 describes the axioms used to deal with some of the more interest- 



ing linguistic constructions; Section [4/i] discusses assumption declarations; 
and Section [4.8| briefly examines Horn-clause axioms. In the final section, 
we present an extended example showing translation of a complex query. 



4.2.1 Names and objects 

For reasons explained in Section \2.3[ we regard the terms appearing as ar- 
guments to database predicates as referring not to entities in the exterior 
world, but rather to "database objects", which in practice can be taken to 
mean strings of characters. Since the linguistic predicates are intended to 
range over real-world objects, it is necessary to provide some way of relating 
objects to their database identifiers. This is done through the naming pred- 
icates. The intuition is that database identifiers are names, but not unique 
names: they need to be associated with some extra information to become 
unique. For example, there are some numbers which are both cheque and 
transaction IDs; the fact that a cheque ID happens to be identical with a 
transaction ID does not imply that the cheque and transaction are identical, 
or even that they are related. 

The LDT deals with these problems by assuming that the named objects 
referred to by the theory can be divided up into a set of discrete subsets called 
types, such that names are unique within each type; it is also convenient to 
introduce identifiers for the types, and to allow terms of the form 

<Type>#<Name> 

to be regarded as referring to "the object of type <Type>, with identifier 
<Name>" . If the types can be identified with the extensions of English NBAR 
senses, then the typed objects can be described by noun-phrases consisting 
of the NBAR followed by the name. Thus for example the typed object 
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transactionl#123 can be referred to by the English noun-phrase transac- 
tion 123. In practice, all the types used in the PRM LDT are identified with 
NBAR senses in the way just described. 

Three kinds of database objects that need to be treated specially are 
those explicitly referring to numbers, amounts and dates. To deal with 
these, there are three predicates that relate these database objects to terms 
in the theory that represent the objects they name; for uniformity there is 
also a fourth predicate, which encodes the relationship between a database 
ID, a type, and the resulting typed object. The fourth predicates are 

sql_number_convert (Num,DBNum) Num is the number of which DBNum is the 
name. In the current implementation, Num is a Prolog number, and 
DBNum is a Prolog atom whose print-name is the same as that of Num. 
Surprisingly, distinguishing between these two types of object actually 
turns out to be very helpful in terms of simplifying the mechanics of 
the low-level SQL interface. 

amount_object( Amount, Unit, Num) AmountObject is an object represent- 
ing the quantity of size Num, measured in the unit Unit. 

sql_date_convert (Date ,DBDate) DBDate is the database representation of 
the date Date. In the current implementation, Date is a structured 
term whose components represent the day, month and year of the 
date; DBDate is a Prolog atom whose print-name encodes the SQL 
representation of the date. 

named_object(TypedObject,Type,Id) TypedObject is the unique typed 
object (cf Section 4.2.1) with type Type and database ID Id. 



4.2.2 "Conceptual" predicates 

Because of the very conservative semantics we have assigned to the database 
predicates, they are difficult to work with directly. It is consequently useful 
to pair each database predicate P^b with an "idealized" version which we call 
the corresponding conceptual predicate, P CO nc- The exact general relationship 
between the "database" and "conceptual" versions of predicate is not meant 
to be strictly defined, but the following guiding priniples have been found to 
be useful: 

• Each argument Arg^b in P^b should have a corresponding argument 
Arg conc in P con c- If Arg^b is an identifier, then Arg conc is the object it 
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identifies; if it is a "code" (e.g. a yes/no value), then the values of the 
two arguments should be equal. 

• An extra argument should be added to P conc if Pdb has no primary key 
field. This argument will often end up corresponding to the "entity" 
argument in verbs that translate into P conc . 

• In some cases, other extra arguments may need to be added to Pconc 
corresponding to objects that can be referred to in natural language in 
connection with Pdb, but which are always assumed to have the same 
value. For example, all the transactions in the database have been 
made by SRI, and this is implicit in the semantics of the TRANS relation. 
Since SRI can however be explicitly referred to in English as making 
payments, it is helpful to have an argument in the conceptual predicate 
corresponding to TRANS which holds the "payer" in the transaction. 

• "Contingent" restrictions relating to Pdb should not apply to Pconc-, 
for example that the record only holds of events occurring within a 
specified period. The contingent completeness information is added 
instead as part of the formulas relating Pdb and Pconc- 

The brief discussion above should motivate the following definitions of the 
conceptual predicates associated with the database predicates in the PRM 
LDT. We will describe the axioms that relate each database predicate to its 



associated conceptual predicate later, in Section 4.5. For the moment, we 
leave the connection between them informal. 

transact ion (Trans , Payer , Cheque , Date , Payee , Account , Amt ) 

Trans is a payment made by Payer to Payee on the day Date. The amount 
was Amt and the payment was accomplished using Cheque; it was charged 
to Account. Note that the new argument Payer has been added, and the 
restrictions concerning the permitted range of dates dropped. Most im- 
portantly, the arguments are all objects in the exterior world rather than 
strings. 

pro j ect (Pro j ect , Organisation , Account , Start , End) 

Project is a project at Organisation. It has the associated account Account, 
the start date is Start, and the end date is End. Once again, a new argument 
(Organisation) has been added. 
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payee (Payee , Type) 

Payee is a payee of the type defined by Type. Here, the difference between 
the conceptual and database predicates is minimal. 

employee (Employee , Organisation , Sex , HasCar ) , 

Employees at Organisation, classified by their sex and whether or not they 
have a company car. 

booking_to_project (Event .Person, Time, Date .Project) 

Since the TIMESHEET predicate has no primary key, the argument Event is 
added, corresponding to the event of Person's booking the quantity of time 
Time to Project on Date. 

Database relationships are usually functions on at least one of their ar- 
guments (those that correspond to primary keys); as just discussed, concep- 
tual relations always have this property, if necessary by construction. The 
translation mechanism is able to make use of information about functional 
relationships in several ways (cf |3.6.2| ) . Functional relations are defined by 
declarations of the form 

f unction(<Template> , <From> -> <To>) 

This is to be read as stating that in <Template>, an assignation of values to 
the variables making up the list <From> uniquely determines the values of 
the variables in the list <To>. 

Function declarations of this type are consequently supplied both for 
database and conceptual predicates. For example, the declarations for TRAMS 
and transaction are 

function (TRANS (Trans Id, Cheque Id, Date , Payee , Acc , Amt) , 

( [Transld] -> [Chequeld, Date, Payee, Acc, Amt] )) 

function (TRANS (Tr ans Id, Cheque Id, Dat e , Payee , Acc , Amt) , 

([Chequeld] -> [Transld, Date, Payee, Acc, Amt] )) 

f unct ion (transact ion (Trans , Payer , Cheque , Date , Payee , Acc , Amt ) , 
([Trans] -> [Payer, Cheque, Date, Payee, Acc, Amt] )) 

f unct ion (transact ion (Trans , Payer , Cheque , Date , Payee , Acc , Amt ) , 
([Cheque] -> [Payer, Trans, Date, Payee, Acc, Amt] ) ) 

Either the transaction ID or the cheque number could be used as a primary 
key, and hence there are two functional declarations for each predicate. 
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4.2.3 "Attribute" predicates 

There is a second general class of intermediate predicates that we have found 
it helpful to introduce; we call these "attribute" predicates. Attribute pred- 
icate receive their name because they are used to associate an object or 
event with a characteristic attribute, such as time of occurrence or magni- 
tude. There is one attribute predicate for each such attribute. Introducing 
the attribute predicates makes the LDT more modular. For example, most 
temporal prepositions translate directly or indirectly into expressions involv- 
ing the time associated with an object; however, the target predicates used 
to express the relationship between an object and its associated time de- 
pend on the nature of the object. By introducing the attribute predicate 
associatecLtime, it is possible to produce a modular solution. The predi- 
cates representing the preposition senses are first translated, using domain- 
independent equivalences, into a representation expressed in terms of the 
associatecLtime predicate; then domain-dependent equivalences (one for 
each relevant type of object) translate associatecLtime into conceptual 
predicates. 

In the PRM LDT, we use four attribute predicates. There are three tem- 
poral attribute predicates, associatecLtime, associated_start_time and 
associatecLencLtime, which are produced as intermediate translations of 
word-sense predicates for words like when, during, after, start and end. Each 
temporal attribute predicate is a three-place predicate, whose arguments are, 
in order 

• the object (which will often be an event) 

• the associated date or time 

• the "granularity" of the date or time, which at present must be either 
days or seconds 

The fourth attribute predicate associated_size, has two arguments. It is 
produced as a result of translating linguistic predicates denoting the "size" or 
"magnitude" of an objects, which mainly arise in constructions that compare 
objects with reference to their extent. Expressions of this form include com- 
paratives (larger, smaller) superlatives (largest, smallest), and some prepo- 
sitions like over (over £250). 
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4.3 General axioms 

In the next three sections, we describe the axioms of the PRM LDT: as indi- 
cated earlier, these are divided into three groups, which we refer to as "gen- 
eral", "domain-specific" and "database-specific" respectively. About 195 of 
the axioms fall into the first, "general" group. About 45 of them translate 
words used to refer to concepts in the utterance situation (show, question, 
answer etc.) into representations in terms of the primitive executable pred- 
icates. For the sort of modularity reasons already referred to, translation is 
in fact carried out in three stages. The linguistic word-sense predicates are 
first translated into an intermediate form, expressed in terms of the predi- 
cates execute and display .format. For example a typical equivalence of 
this type would be the following one, that translates the ditransitive verb 
show (Show me the payments): 

show2 (Event , Agent , X , Audience) <-> 
exists ( [Time , Format] , 

and(display_f ormat (X, Format) 

execute (Event , display (Format) , Agent , Audience , Time) ) 

The right-hand side of the above equivalence expresses the fact that a "show- 
ing" of an object X by Agent to Audience involves finding a suitable display 
format Format, and then displaying Format. In practice, Agent will be clare 
and Audience a term referring to the user. In the second round of transla- 
tion, the predicate display J ormat is replaced by a representation in terms 
of "conceptual" predicates, in a way that is dependent on the nature of X: 
this is discussed later, in Section 4.6.3| . Finally, goals of the form 



execute (Event , Action, clare , <User> ,Time) 
are translated into one of the two forms 
execute_in_f uture (Action) 



or 



executed_in_past (Action) 

depending on whether the context makes Time after or before the present 
moment. This division mirrors the important pragmatic distinction between 
future actions, which can be caused to occur if the system so desires, and 
past actions, which can be "remembered" by consulting the action log. 
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Of the remaining "general" axioms, about 100 translate basic word senses, 
like temporal prepositions and size expressions, into the "attribute predi- 
cates" described in Section |4.2.3 above. A simple example is provided by 



the predicate corresponding to the the temporal preposition during, which 
is translated by the equivalence 

duringl(El,E2) <-> 

exists ( [Tl , T2 , Granl , Gran2] , 

and(associated_time (El ,T1 , Granl) , 

and(associated_time (E2 ,T2 ,Gran2) , 

time_during( [Tl, Granl] , [T2 , Gran2] ) ) ) ) 

This expresses the fact that an event El can be regarded as being "during" 
another event E2 if the time associated with the first event is contained 
in the time associated with the second one. The arguments Granl and 
Gran2 express the conceptual level of granularity of the events El and E2; at 
present they can be either days (appropriate for database events) or seconds 
(appropriate for utterance situation events). Note that the definition of 
the associated_time predicate is provided by domain-specific axioms; the 
equivalence performs the domain-independent function of translating the 
linguistic predicate duringl into a more convenient form expressed in terms 
of the general predicates associated_time and time_during. 

The inherently vague nature of many prepositions, however, means that 
an extra level of indirection is often required to translate them. The predicate 
corresponding to the preposition is first translated by a conditional equiva- 
lence into a second predicate representing a specialized preposition-sense; the 
conditions reflect suitable constraints on the preposition's arguments. The 
preposition sense predicate can then be translated into "attribute predicates" 
by equivalences like the one for duringl shown above. For instance, the fol- 
lowing conditional equivalence is in the PRM LDT sufficient to deal with 
the temporal sense of the preposition from, as in from 1/3/90 to 15/5/90: 

(froml(X,Y) <-> from_Temporal(X,Y)) <- 
temporal_entity (Y) . 

The predicate temporal_entity is defined by Horn-clauses to hold of dates, 
times and a few other similar objects. 

The final set of about 30 general rules deal with translations of pred- 
icates like time_during, which relate times; the complications are caused 
by the fact that "times" can be either points or intervals, and can also be 
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expressed at different levels of granularity. The temporal axioms translate 
all the temporal predicates into a uniform representation in terms of a single 
predicate, time_point_precedes, that compares time-points with regard to 
temporal precedence. 



4.4 Domain-specific axioms 

The axioms of the second group, which for the PRM domain are some- 
what less numerous than the first, are domain-specific but not database- 
specific. They translate predicates representing senses of domain words 
(project, transaction, deliverable etc.) and "attribute" predicates like asso- 
ciate cLtime, into representations expressed in terms of the conceptual pred- 



icates of Section 4.2.2. 



Translation of both domain word-sense predicates and attribute pred- 
icates is frequently dependent on the nature of their arguments, and the 
corresponding equivalences are thus either conditional or have complex left- 
hand sides. For example, the time associated with a payment is the transac- 
tion date, but that associated with a project is the interval spanned by the 
start- and end-dates. The equivalences that express this are 

and(associated_time (Trans , Date .Granularity) , 

transactionl (Trans) ) <-> 
exists ( [Payer, Cheque, Payee, Acc,Amt] , 

and (transact ion (Payer , Trans , Cheque , Date , Payee , Acc , Amt ) , 
Granularity = days)) 



and(associated_time (Project , Interval , Gran) , 

projectl(Project) ) <-> 
exists ( [StartDate , EndDate] , 

and (pro j ect (Org , Pro j ect , Account , StartDate , EndDate) , 
Interval = interval (StartDate, EndDate)) 

Other examples of domain-specific equivalences can be found at the begin- 



ning of Section 4.6 



4.5 Database-specific axioms 

The third group of axioms relate the conceptual predicates to the associ- 
ated concrete database predicates. They capture specific coding peculiarities 
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which relate database-objects and their associated real-world counterparts, 



which, as explained above in section 2.6, includes contingent limitations on 



the availability of recorded data. The database-specific group is small, con- 
sisting of about 25 axioms; these consist of one or more equivalence linking 
each conceptual predicate to its concrete counterpart, together with some 
axioms that define the "contingent limitations" when necessary. For exam- 
ple, the equivalences that relate the database predicate TIMESHEET and its 
conceptual counterpart book_time_to_project (slightly simplified) are 

(book_time_to_project (Ev,Emp, Amt ,Date , Acc) <-> 
book_time_to_project_recorded(Ev,Emp, Amt ,Date , Acc) ) <- 
timesheet_data_available (Date , Acc) 

exists ( [Ev] , 

book_t ime_to_pro j ect_recorded (Ev , Emp , Amt , Date , Acc) <-> 
exists ( [EmpId,DBDate ,AccId] , 

and (TIMESHEET (Empld , Amt , DBDate , Accld) , 

and (named_ob j ect (Emp , employee 1 , Empld) , 
and(sql_date_convert (Date, DBDate) , 

named_ob j ect (Acc , account 1, Accld))))) 

The first of these is a "universal" equivalence, that encodes the contin- 
gent completeness restrictions. It consults the predicate timesheet_data_- 
available to find out whether Date is within the range for which timesheet 
data on account Acc has been recorded. timesheet_data_available is de- 
fined by a set of Horn-clauses (one for each account), of the form 

timesheet_data_available (D , <CLAREAccount>) <- 

and(time_point_precedes (nonstrict , <CLAREStartDate> ,D) , 

time_point_precedes (nonstrict ,D , <CLARELastRecordedDate>) ) 

timesheet_data_available (D , <SLTAccount>) <- 

and(time_point_precedes (nonstrict , <SLTStartDate>,D) , 

time_point_precedes (nonstrict ,D , <SLTLastRecordedDate>) ) 

where <CLAREAccount> is a ground term representing the CLARE account, 
and so on. The second, "existential" equivalence above uses the "naming" 
predicates named_object and sql_date_convert to relate the real-world ob- 
jects referred to by book_time_to_project and the database identifiers in 
TIMESHEET. 
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Most of the permissible assumptions that can be made are related to 
the database-specific axioms, and are of one of two types. The first type, 



ments like "employer" in the project conceptual relation or "payer" in the 
transaction relation are filled by SRI unless explicitly filled by something 
else. There is a predicate, assumably_=, to deal with this situation: we il- 
lustrate with the project relation. The equivalence that translates it into 
the associated database predicate is schematically of the form 

(project (Pro j ,Org,Acc,StartDate,EndDate) <-> 
... <Right-hand side> ...) <- 
as sumably _= ( Org , 

organizationl#sri , 

all_projects_ref erred_to_are_at_SRI) 

The content of the condition on this equivalence is that Org should be equal 
to organizationl#sri. If it is not, it may be assumed to be, with the "jus- 
tification" all_projects_ref erred_to_are_at_SRI. The intended semantics 
of the predicate assumably_=, as the name suggests, are that it should hold 
if the first two arguments are equal; otherwise, they can be assumed equal, 
with the third argument serving as a "justification". This is specified by the 
following Horn-clause and assumption declaration: 

assumably_=(X,Y, Justification) <- X=Y 
assumable (assumably_=(X,Y, Justification) , 



The second main type of assumption, a "limitation" , is related to tempo- 
ral incompleteness of database records: here, the declaration is to the effect 
that it is permissible to assume that data is within the period for which 
records have been kept unless the conjunctive context implies the contrary. 
We illustrate with the timesheet_data_available predicate above. There 
is one assumption declaration for each account. The declaration for the 
CLARE account is for example 

assumable ( 

timesheet_data_available(D, <CLAREAcc>) , 



a "specialization 1 




permits the assumption that argu- 



0, 

Justification, 
specialization 
true) 
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15, 

time_was_booked_af ter_<CLAREStartDate>_and_\\ 

bef ore_<CLARELastRecordedDate> , 

limitation, 
true) ) 

4.6 Specific linguistic constructs 

In this section, we will describe the types of equivalences used to translate 
some specific types of linguistic constructs. We begin with the unproblem- 
atic cases, in which a linguistic predicate can directly be mapped into a 
relation on one more slots of a conceptual or attribute predicate. (We will 
use the term "conceptual slot" as a handy abbreviation for "argument of 
a conceptual predicate"). The simplest case is perhaps that of a common 
noun which describes a conceptual slot. In the following example, the rule 
says that an object which fills the third argument place in the conceptual 
transaction relation can be described by the predicate chequel. 

che quel (Cheque) <-> 

exists ( [Payer, Trans, Date, Payee, Acc,Amt] , 

transaction (Trans , Payer , Cheque , Date , Payee , Acc , Amt ) ) 

Slightly more complex rules are used to translate many domain-specific 
preposition senses. The following are the equivalences that cover "cheque 
for amount" (cheques for more than £200), "cheque to payee" (cheque to 
Maxwells) and "cheque on account" (cheques on account 8468): 

and(for(Cheque,Amt) , 

chequel (Cheque) ) <-> 
exists ( [Trans, Payer, Date, Payee, Acc, Amt] , 

transact ion (Trans , Payer , Cheque , Date , Payee , Acc , Amt ) ) 

and (to (Cheque, Payee) , 

chequel (Cheque) ) <-> 
exists ( [Trans, Payer, Date, Payee, Acc, Amt] , 

transaction (Trans , Payer , Cheque , Date , Payee , Acc , Amt ) ) 

and (on (Cheque, Acc) , 

and(chequel (Cheque) , 

account 1 (Acc) ) ) <-> 
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exists ( [Trans, Payer, Date, Payee, Acc,Amt] , 

transact ion (Trans , Payer , Cheque , Date , Payee , Acc , Amt ) ) 

In all these examples, the conditions on applicability are provided by extra 
conjuncts on the LHS. Similar considerations apply to many verb senses: 
the following, for example, is the rule that covers "pay money to" , as in SRI 
paid £120 to Maxwells. 

and (pay2 (Trans, Payer, Amt, Payee) , 

money 1 (Amt) ) <-> 
exists ( [Payer , Date , Acc] , 

transaction (Trans , Payer , Cheque , Date , Payee , Acc , Amt ) ) 

Note that the "paying event" is regarded as being the same as the trans- 
action, and that the agent of the paying event becomes the Payer in the 
conceptual transaction relation. 

In the remainder of this section, we consider constructions that require 
equivalences of a different or more complex form. 

4.6.1 Translating "attribute" predicates 

"Attribute" predicates can be translated in much the same way as the lin- 
guistic predicates we have seen above. Domain-dependent equivalences are 
provided to translate the attributes predicates in the contexts provided by 
the domain word-senses: the right-hand sides of these equivalences will usu- 
ally contain conceptual predicates. The following rule, for example, trans- 
lates the associatecLtime predicate in a context where its first argument is 
a transaction; it states that the fourth field of a transaction relation is the 
time (at the level of granularity of days) associated with the transaction. 

and (associatecLtime (Trans , Date , Granularity) , 

transactionl (Trans) ) <-> 
exists ( [Cheque, Payer, Payee, Acc, Amt] , 

and (transact ion (Trans , Payer , Cheque , Date , Payee , Acc , Amt) , 
Granularity = days)) 

Similarly, the following pair of rules state that the start and end dates of a 
project are encoded in the fourth and fifth fields of the project relationship 
respectively. 

and (associated_st art _time (Project , St artDate, Granularity) , 
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projectl (Project) ) <-> 
exists ( [Org, ProjNum,EndDate] , 

and (pro j ect (Pro j ect , Org , Pro jNum , StartDate , EndDate) , 
Granularity = days)) 

and(associated_end_time (Project , EndDate .Granularity) , 

projectl(Project) ) <-> 
exists( [Org, ProjNum, StartDate] , 

and (pro j ect (Pro j ect , Org , ProjNum , StartDate , EndDate) , 
Granularity = days)) 

The associated_size primitive predicate takes two arguments: the first is 
the object in question, and the second is its "size", which is represented as 
number. Finding a suitable number usually involves including a goal in the 
RHS which extracts the number from a term representing an amount. In 
the following example, which defines the "size" of a cheque, the extraction 



is performed using the amount .object predicate (cf Section 4.2.1). 



and (associated_size (Cheque, N) , 

chequel (Cheque) ) <-> 
exists ( [Trans, Payer, Date, Payee, Acc,Amt] , 

and (transaction (Trans , Payer , Cheque , Date , Payee , Acc , Amt) , 
amount_ob j ect (AM , sterling_unit , N) ) ) 



4.6.2 Support verbs 

Support verb constructions like "make a payment" also demand a slightly 
different treatment. The next example shows the relevant equivalence: 

and (make2 (MakeEvent , Payer , Trans ) , 

payment 1 (Trans) ) <-> 
exists ( [Cheque, Date, Payee, Acc, Amt] , 

and (transact ion (Trans , Payer , Cheque , Date , Payee , Acc , Amt) 
MakeEvent = Trans)) 

Here the "making" event is once again regarded as being the same as the pay- 
ment. In cases like this, where two variables from the LHS (MakeEvent and 
Trans) are to be mapped onto a single event on the RHS, the most straight- 
forward solution is to write the rule in the way shown, with an equality on 
the right. It is worth noting that the apparently plausible formula 
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and (make2 (Trans , Payer , Trans ) , 

payment 1 (Trans) ) <-> 
exists ( [Cheque, Date, Payee, Acc,Amt] , 

transact ion (Trans , Payer , Cheque , Date , Payee , Acc , Amt ) ) 

does not achieve the desired end, and is not in fact equivalent with the pre- 
vious one. The easiest way to convince oneself of the truth of this statement 
(which may seem counter-intuitive to readers used to Horn-clauses) is to 
consider the pair of formulas 

p(X,Y) <-> and(q(X),X = Y) 

and 

p(X,X) <-> q(X) 

The first of them means that p(a,b) implies q(a), but not the second. 



4.6.3 Predicates referring to identifiers 

Some linguistic predicates can refer to names or numbers, which in the PRM 
LDT are equated with database identifiers. For example, the equivalence 
used to translate the relational sense of the compound noun project number 
(e.g. CLARE's project number) is 

project_number_of (N, Project) , 
exists ( [Org, Start, End, Account] , 

and (pro j ect (Pro j ect , Org , Account , Start , End) , 
named_ob j ect (Account , account 1 , N) ) ) 

Note the use of the predicate named_object on the RHS. This expresses the 
fact that Account is the "typed object" (cf Section 4.2. 1| ) of type account 1 



with identifier N, i.e. the object referred to by the English expression account 
N. 

Equivalences of this type are also used to help translate predicates corre- 



sponding to "displaying" verbs like show and list. As explained in Section [4.3 
above, these are first translated into a uniform representation that uses the 
predicates executable_action/6 and display _format/2. The second of 
these is a predicate which determines the appearance of the term printed to 
represent a database object: the intention is that 



display_f ormat (Object , Format) 
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should hold if Format is either a database object, or a list containing one 
or more database objects, that can be used together as a representation of 
Object suitable for displaying to the user. For example, a transaction can 
be conveniently displayed as a list consisting of its transaction ID, the date 
of the payment, the payee ID, and the amount. This is captured in the 
following equivalence, 

and(display_f ormat (Trans .Format) , 

transactionl (Trans) ) <-> 
exist s ( [Payer , C , Date , Payee , AC , Amt , Transld , DBDate , Payeeld , AmtNum] , 
and (transact ion (Trans , Payer , C , Date , Payee , AC , Amt ) , 
and(named_obj ect (Trans , transactionl , Transld) , 
and(sql_date_convert (Date , DBDate) , 
and(named_object (Payee , payee 1 , Payee Id) , 
and ( amount _obj ect (Amt ,pounds_sterling, AmtNum) 

Format = [Transld, DBDate , Payeeld, AmtNum] ))))) ) 

There is one display jformat definition for each type of object. Many ob- 
jects are "typed objects" whose names serve as adequate descriptions; this 
is for example the case for sponsors in the PRM domain. In cases like these, 
an equivalence like the following one for "sponsors" is sufficient: 

(display_f ormat (Sponsor , Format) <-> 
named_ob j ect (Sponsor , sponsor 1 , Format) ) <- 
sponsorl (Sponsor) . 



4.6.4 Expressions that map onto code values 

The filler of a field in a database relationship is often a code, and an English 
expression can map onto a value, or set of values, for this code; thus for 
example it might easily be the case that a word like man or woman ultimately 
maps onto a field being filled by an m or a w. The problems involved have 



already been discussed at some length in Section |3.7| . Here, we present some 
more examples from the PRM LDT. 

The first and second equivalences below are straightforward. The first 
states that man when applied to an object known to be a payee, maps onto 
the first field of the payee relation being filled by an m (recall that payee 1 
is a predicate corresponding to a wods-sense, while payee is a "conceptual" 
predicate). The second states that an overhead payment is a transaction 
where the "account" field is filled by a numbered object of type "account" 
whose number satisfies the predicate overhead_code. 
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and (manl (Payee) , 

payeel (Payee) ) <-> 
payee (m, Payee) 



overhead_paymentl (Trans) <-> 

exists ( [Payer, Cheque, Date, Payee, Acc,Amt,Num] , 

and (transact ion (Trans , Payer , Cheque , Date , Payee , Acc , Amt) , 
and (numbered_ob j ect (Account , account 1 , Num) , 
overhead_code (Num) ) ) ) 

For the second equivalences, a further definition is needed to specify the 
range of permitted values for overhead codes: they are defined to be exactly 
those numbers which are members of the set {775, 675}. The equivalence 
used is 

overhead_code (Num) <-> member (Num, [775,675] ) 

The third example uses the employee relation, whose third argument is 
set to y if the employee in question has a company car. It illustrates the 



problems discussed earlier in Section 3.7, and involves a code which indicates 



existence or non-existence of an object. The following two rules provide an 
appropriate translation for the relevant predicates company _carl and havel: 

and(company_carl (Car) , 
and(employeel (Empl) , 

havel (Event, Empl, Car))) <-> 
employee_has_car (Event , Empl , Car) 



exists ( [Event , Car] , 

employee_has_car (Event , Empl , Car) ) <-> 
exists ( [Sex] 

employee (Empl , Sex , y) ) 



4.6.5 Transferring properties between objects 

There are several cases in the PRM LDT where two related objects X and 
X' can both have the same property P. We have already seen one example of 
this phenomenon earlier in our discussion of the "Doctor on Board" problem 
(Section |3.7[ ), where both ships and doctors can have positions, and the 
position of a doctor is the same as that of his ship. In all the cases in the 
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PRM domain, it was possible, just as with the ships and doctors, to express 
the relationship between P, X and X' with a simple conditional equivalence. 

We illustrate with the preposition on, used with regard to payments; 
linguistically, payments can be either on accounts {Show me all payments 
on account 8468) or on projects (Which payments on CLARE were over 
£1000?). This is of course a simple example of metonymy. The "payment 
on account" case can be mapped into the TRANS relation, which associates 
payments with account numbers. To deal with the "payment on project" 
case we must first find the project's account number. This can be achieved 
with the following conditional equivalence: 

(onl (X, Project) <-> onl(X, Account)) <- 
pro j ect (Pro j ect , Org , Account , Start , End) . 

which compactly captures the metonymic relationship between the two con- 
texts of use of onl. 



4.7 Assumption declarations 

Most of the assumption declarations in the PRM LDT are of the form de- 



scribed earlier in Section 4J3: they make it permissible to assume that con- 
tingently complete information really is complete for the purposes of the 
question. Assumption declarations are also used in two other contexts. 

Firstly, there are a couple of cases where a word can be assumed to be 
used in a specialized sense: for example, car is normally assumed to mean 
company car. This is achieved by using a conditional equivalence 

(carl(X) <-> company_carl (X) ) <- 
car_is_company_car (X) 

together with the assumption declaration 

assumable (car_is_company_car (X) , 
0, 

all_cars_ref erred_to_are_company_cars , 

specialization, 

true) 



Here, all_cars_ref erred_to_are_company_cars is the "justification" tag 
used to describe the assumption to the user. 
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The second type of assumption declaration is more interesting, and is 
related to the "executable predicates" . Recall that these are predicates which 
the system can cause to become true, by executing actions in the world. If 
they refer to future events, ground executable predicate goals can thus be 
assumed to be true. This is specified by the assumption declaration (slightly 
simplified) 

assumable (execute_in_f uture (Action) , 
0, 

perf orm_action(Action) , 
action, 

ground_action (Action) ) . 

The content of the declaration is that the execution of Action by CLARE 
at some future time can be assumed to be true, if Action is a ground term 
representing an action. The assumption is of the type action, and the 
justification is the term 

perf orm_act ion (Act ion) 

The justification in the case of an assumption of type action is of a spe- 
cial kind: it is in a literal sense a promissory note that the action will be 
carried out by the system at some time in the future. After a proof has 
been completed, CLARE collects together all these action assumptions, and 
discharges them by executing all the actions described in the justification 
tags. 

4.8 Horn clause axioms 

A number of Horn-clause axioms are also used in the PRM LDT. We have 
already seen some examples of Horn-clause axioms in the preceding section, 
used to define conditions under which conceptual and database predicates 
correspond. Two other types of Horn-clause axioms found in the LDT are 
also worth discussing. The first results from the predicate personal/1, 
which holds of entities that can be referred to by the interrogative pronoun 
who. In a normal context like Who works on CLARE? or Who booked time 
to project 8744 this month ?, no information is contributed by the occurrence 
of personal; it is implicit that entities who can work on projects, or book 
time to projects, can be referred to as "who" . This fact is captured in the 
Horn-clauses 
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personal (Person) <- 

works_on_pro j ect (Event , Person , Pro j ect ) . 

personal (Person) <- 

booking_to_pro j ect (Event , Person , Time , Date , Account) . 

The translation process uses these clauses to deduce that the occurrences of 
personal are implied by their contexts, and can safely be thrown away, in 



the way described in Section 3.6,2. 



The second type of Horn-clauses are the "negated goal" axioms used to 



find inconsistent uses of assumptions (cf Section 3J3). These are formulas of 
the type 

neg(Goal) <- Body 

They are not Horn-clauses according to the formal definition of the term, 
but are treated as such by the inference engine (cf Section [5.1.3 ). 



In the current PRM LDT, negated goal clauses are mainly used in con- 
nection with conditions on "limitation" assumptions. For example, we saw 



in Section |4.5| above that the "open" predicate book_time_to_project and 
its "closed" counterpart book_time_to_project_recorded are linked by the 
equivalence 

(book_time_to_project (Ev,Emp, Amt ,Date , Acc) <-> 
book_t ime_to_proj ect _recorded (Ev, Emp, Amt , Date , Acc) ) <- 
timesheet_data_available (Date , Acc) 

where timesheet_data_available is a predicate, defined by normal Horn- 
clauses, that gives sufficient conditions for timesheet data having been recorded. 
A typical clause, giving sufficient conditions for timesheet data on CLARE 
to have been recorded, was 

timesheet_data_available(D, <CLAREAccount>) <- 

and(time_point_precedes (nonstrict , <CLAREStartDate> ,D) , 

time_point_precedes (nonstrict ,D , <CLARELastRecordedDate>) ) 

Now we can make these conditions necessary as well, by adding the corre- 
sponding negated clauses 

neg(timesheet_data_available(D,<CLAREAcc>) ) <- 
time_point_precedes (strict ,D , <CLAREStartDate>) 

neg(timesheet_data_available(D,<CLAREAcc>) ) <- 

time_point_precedes (strict , <CLARELastRecordedDate> ,D) 
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As can be seen, these state that timesheet data is explicitly not recorded for 
dates outside the specified period. 

The following negated goal clause is provided for the predicate assumably_ 



described in Section 4.5: 



neg(assumably_=(X,Y, Justification) ) <- 
different _ground_terms (X, Y) 

This makes it inconsistent to assume that distinct ground terms are equal. 
The predicate dif f erent_ground_terms is defined in a way that treats spe- 
cially the unique constants introduced by translation schemas for construc- 
tions that bind variables (cf Sections p. 2.1 and 3.4). These unique constants 



are not considered to be ground terms for the purposes of the different. 
ground_terms predicate. 



4.9 A full example 

In this final section, we present a detailed example showing how CLARE 
uses the PRM linguistic domain theory to find an effective translation of the 
TRL representation of sentence (SI) (repeated here for convenience). 

(SI) Show all payments made to BT during 1990. 

We will take a few liberties with the exact representation of the domain 
axioms in the interests of increased readability. In particular we have sup- 
pressed the complications caused by the treatment of granularity of time, 
and removed some arguments from predicates when they were irrelevant to 
the example. To make the formulas more compact, we also introduce the 
minor notational abbreviation of writing E instead of exists to represent 
existential quantification, and A instead of forall to represent universal 
quantification. 

The original TRL representation of (SI) is 

A( [Trans] , 

impl (E ( [Agnt , Ev] , 

and (payment 1 (Trans) , 

and(make2 (Ev, Agnt , Trans , payee l#bt) , 
duringl (Ev , yearl#1990) ) ) ) , 
E( [ShowEv] , 

and (showl (ShowEv, clare , Trans) , 
bef orel (<Now> , ShowEv) ) ) ) ) 



4.9. A FULL EXAMPLE 



97 



(We write <Now> to stand for the TRL representation of the present moment). 
The formula can be glossed as "For all Trans such that Trans is a payment 
made by some Agent during the year 1990, it is the case that CLARE will 
show Trans at some time after the present time". 

The desired effective translation will be expressed in terms of three 
evaluable predicates. The database information is accessed by the pred- 
icate TRANS (TransId,DBDate ,PayeeName , Amount). We have omitted the 
Chequeld and Account arguments, since they play no part in the derivation; 
we have also removed the corresponding arguments from the associated con- 
ceptual predicate, transaction. Dates are manipulated by the arithmetic 
predicate time_point_precedes (shortened to t_precedes), which holds if 
its arguments are two representations of calendar dates such that the first is 
temporally before the second. Execution of actions is represented as usual 
by the predicate 

execute_in_f uture (Action) 

(cf Section [i.3| ). The actions we are interested in here are displaying ac- 
tions carried out by CLARE: these will be represented as terms of the form 
display (FormatList) where FormatList is a list of objects to be displayed. 

The first step is to use equivalences which translate the linguistic predi- 
cates paymentl, make2, duringl, showl and bef orel into conceptual pred- 
icates. Replacing bound variables with unique constants marked with aster- 
isks, 

paymentl (Trans*) 

is first translated to 

E ( [Payer , Date , Payee , Amt] , 

transact ion (Trans * , Payer , Date .Payee , Amt) ) 

using the domain-specific equivalence 

transactionl (Trans) <-> 
E ( [Payer , Date , Payee , Amt] , 

transact ion (Trans , Payer , Date , Payee , Amt) ) ) . 

Then 

make2 (Ev* , Agnt* , Trans* ,payeel#bt) 

is translated into 
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E( [Datel.Amtl] , 

and (transact ion (Ev* , Agnt* ,Dat el ,payeel#bt , Amtl) , 
Ev*=Trans*)) 

using the rule 

and (make2 (Payer , Event , Payment , Payee) , 

transactionl (Payment) ) <-> 
E( [Date, Amt] , 

and (transact ion (Event , Payer , Date , Payee, Amt) , 
(Event = Payment)) 

The next rule to be applied is the one that translates duringl. The intended 
semantics of duringl (El ,E2) are "El and E2 are events, and the time asso- 
ciated with El is inside that associated with E2". The relevant equivalence 
is 

duringl (El, E2) <-> 
E( [Datel,Date2] , 

and(associated_time(El ,Datel) , 

and(associated_time(E2,Date2) , 
time_during(Datel ,Date2) ) ) ) 

This translates 

duringl (Ev*, year 1#1990) 

into 

E( [Datel,Date2] , 

and(associated_time(Ev* ,Datel) , 

and(associated_time (year#1990,Date2) , 
time_during(Datel ,Date2))) ) 

This can now be translated further by using equivalences for associated_time. 
For the first conjunct, the appropriate one is 

and (associated_time (Trans , Date) , 

transactionl (Trans) ) <-> 
E ( [Payer , Payee , Amt] , 

transaction (Trans , Payer , Date , Payee , Amt) ) 

which says that the associated_time of a transaction is its third argu- 
ment; for the second conjunct, we have 
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associated_time (yearl#YearNum,Time) <-> 

Time = interval (date (YearNum, 1 , 1) , date (YearNum, 12 ,31) ) 

which says that the time associated with a year is the interval starting on 
the first of January and ending on the 31st of December. Applying these in 
turn, we get a representation of 

duringl(Ev*,yearl#1990) 

in terms of conceptual predicates, namely 

E ( [Payer2 , Date2 , Payee2 , Amt2] , 

and (transact ion (Ev* , Payer2 , Date2 , Payee2 , Amt2) , 
time_during(Date2, interval (date ( [1990, 1,1] ) , 

date ([1990,12,31]))))) 

Next 

showl (ShowEv* , clare , Trans*) 

is translated by the following two equivalences. The first, a "general" axiom, 

showl (E, Agent, X) <-> 
E( [DisplayT, Format] , 

and(execute(E,display(Format) , Agent , DisplayT) , 
display_f ormat (X, Format ) ) ) 

can be glossed "A showing of X by Agent is the execution of a displaying of 
Format, where Format is the display-format of X". The second, 

and (display_f ormat (Trans , Format) , 

transactionl (Trans) ) <-> 
E ( [Transld , Payer , Date , DBDate , Payee , Payeeld , Amt , AmtNum] , 
and (transact ion (Trans , Payer , Date , Payee , Amt) , 
and(named_obj ect (Trans , Transld , transaction) , 
and(sql_date_convert (Date , DBDate) , 
and(named_object (Payee , Payee Id, payee 1) , 
and (amount _obj ect (Amt , pounds , AmtNum) , 

Format = [Transld, DBDate , Payeeld, AmtNum] ))) ) 



(see section 4,6.3; ) is a context-sensitive domain-dependent equivalence which 



defines the display-format for a transaction to be a four-element list consist- 
ing of the transaction ID, the transaction date, the payee's name, and the 
amount. The result of applying both of these is 
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E( [Trans Id, Date3,DBDate ,Payee3, Payee Id, Amt 3, AmtNum, DisplayT] , 
and(execute (ShowEv* , display ( [Trans Id, DBDate , Payee Id, AmtNum] ) , 
clare ,DisplayT) , 
and(transaction(Trans* , Payer3 , Date3 , Payee3 , Amt3) , 
and (Trans*=transact ionl#Id , 
and(sql_date_convert (Date , DBDate) 
and (Payee3=payee l#PayeeId , 

Amt3=amount (AmtNum, pounds) )))))) 

Finally, 

bef orel (<Now> , ShowEv*) 
is translated into 

E( [Formatl ,DisplayAgent ,DisplayT] 

and (exe cut e( ShowEv* , Format 1 , Display Agent ,DisplayT) , 
time_bef ore (<Now> , DisplayT) ) ) 

using rules similar to those used above to translate duringl. When all the 
rules mentioned so far have been applied, the translated form is 

A( [Payer , Trans , Date , Payee , Amt , Payer 1 , Date 1 , Amtl ,Payer2 , 
Date2,Payee2,Amt2] , 
impl (and (transaction (Trans , Payer , Date , Payee , Amt) , 

and (transact ion (Trans , Payer 1 , Date 1 , payee l#bt , Amtl) 
and (transaction (Trans , Payer2 , Date2 , Payee2 , Amt2) 
time_during(Date2 , 

interval (date ( [1990 ,1,1]), 

date( [1990, 12,31] )))))) , 
E ( [Transld , Date3 , DBDate , Payee3 , Payeeld , Amt3 , AmtNum , 
DisplayEv , Format 1 , DisplayAg , DisplayT3 , DisplayT] , 
and (execute (DisplayEv, 

display( [Id, DBDate, Payeeld, Amt 3] ) , 
clare , 
DisplayT 1) , 

and (execute (DisplayEv, Formatl , DisplayAg, DisplayT) , 
and(time_bef ore (<Now> , DisplayT) , 
and (transaction (Trans , Payer3 , Date3 , Payee3 , Amt3) , 
and(Trans=transactionl#Id, 
and(sql_date_convert (Date , DBDate) , 
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and (Payee3=payee l#PayeeId , 

Amt=amount (AmtNum, pounds) )))))))))) 

Exploiting the fact that transaction and execute are both functional on 
their first argument, this reduces after simplification involving functional 
merging (see section 3.6.2| ) to 

A ( [Payer , Trans , Date , Payee , Amt] , 

impl (and (transact ion (Trans .Payer, Date , payee l#bt , Amt) , 
time_during(Date , 

interval (date ( [1990 ,1,1]), 

date( [1990,12,31] )))) , 
E( [Transld, DBDate, AmtNum, DisplayT] , 
and(Trans=transactionl#TransId, 
and(sql_date_convert (Date , DBDate) , 
and (Amt=amount (AmtNum, pounds) , 
and(execute (DisplayEv , 

display ( [Transld, DBDate, bt, AmtNum] ) , 
clare , 
DisplayT) , 
time_bef ore (<Now> , DisplayT) ))))))) 

Applying "general" equivalences to translate time_bef ore and time_during 
into t_precedes, we get 

A ( [Payer , Trans , Date , Payee , Amt] , 

impl (and (transact ion (Trans , Payer , Date , payee l#bt , Amt) , 
and (t_precedes (date ( [1990, 1, 1] ) ,Date) , 

t_precedes (Date , date ( [1990 ,12,31])))), 
E( [Transld, DBDate, AmtNum, DisplayT] , 
and (Trans=transact ionl#TransId , 
and(sql_date_convert (Date, DBDate) , 
and ( Amt = amount (AmtNum, pounds) , 
and(execute (DisplayEv , 

display ( [Transld, DBDate ,bt , AmtNum] ) , 
clare , 
DisplayT) , 
t_precedes (<Now> , DisplayT) ))))))) 

We then apply more "general" equivalences to translate execute into execute. 
in_future, reducing the previous form to 
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A ( [Payer, Trans, Date, Payee, Amt] , 

impl (and (transact ion (Trans , Payer , Date , payee l#bt , Amt) , 
and (t_precedes (date ( [1990, 1,1]) ,Date) , 

t_precedes (Date , date ( [1990 ,12,31])))), 
E( [TransId,DBDate,AmtNum] , 

and (Trans=transact ionl#TransId , 
and(sql_date_convert (Date,DBDate) , 
and(Amt=amount (AmtNum, pounds) , 
and(execute_in_f uture( 

display ( [TransId,DBDate ,bt , AmtNum] )))))))) ) 

Now we apply the equivalence that translates the conceptual predicate trans- 
action into the database predicate TRANS: 

(and (transact ion (Trans , Payer , Date , Payee , Amount ) , 

transaction_data_available (Date) ) <-> 
E( [TransId,AMNum,PayeeName,DBDate] , 

and (TRANS (Transld , DBDate , PayeeName , AMNum) , 
and(named_object (Trans , Transld, transact ionl) , 
and(named_object (Payee , PayeeName , payee 1) , 
and(sql_date_convert (Date , DBDate) , 
amount_object (Amoun, pounds , AMNum) )))))) <- 
assumably_= (Payer , 

organization#sri , 

payment s_referred_to_are_from_SRI) 

When the equivalence is applied to the goal 

tr ansact ion (Trans* , Payer * , Date* , payee l#bt , Amt*) 

its conjunctive context is the set 

{t_precedes (date (1990, 1,1) ,Date*) , 
t_precedes (Date* , date (1990 ,12,31)} 

There are two conditions that must be proved from the context for the rule 
to be applicable, 

assumably_= (Payer* , 

organizationl#sri , 

payment s_referred_to_are_from_SRI) 

and 
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transaction_data_available(Date*) 

The first of these cannot be proved, but the assumption declaration 

assumable (assumably_=(X,Y, Justification) 
0, 

Justification, 

specialization, 

true) 



(cf Section 4.5) makes it permissible to assume it with justification payments. 



ref erred_to_are_f rom_SRI. The validity of the other condition can be in- 
ferred from the context. The axioms needed to do this are two Horn-clauses: 
one defines the period for which transaction records exist, viz. 

transaction_data_available(Date) <- 
and(t_precedes(date(l,8,89) ,Date2) , 
t_precedes (Date, date (1,4, 91))) 

and the other encodes the fact that t_precedes is transitive, 

t_precedes (Datel ,Date3) <- 

and(t_precedes (Datel ,Date2) , 
t_precedes (Date2,Date3) ) 

By chaining backwards through these to the context, it is then possible to 
prove that transaction_data_available (Date*) holds, and translate to 
the final form 

A ( [Transld , Date , DBDate , AmtNum] , 

impl (and (TRANS (Transld , DBDate , bt , AmtNum) 

and(sql_date_convert (Date , DBDate) , 

and (t_precedes (date ( [1990, 1 , 1] ) .Date) , 

t_precedes (Date, date ( [1990,12,31] ))))) 
execute_in_future (display ( [Transld, DBDate ,bt , AmtNum] ) ) ) ) 



The final formula admits a finite proof procedure, (cf sections 2.4.2 and |5.3| ), 
since its truth can be ascertained by an algorithm that can be summarized 
as 



1. Search for all tuples from the finite TRANS relation. 
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2. Check each to find the ones where the Payee field is equal to bt and 
the Date field is suitably constrained by the arithmetic predicates 
sql_date_convert and t_precedes 

3. Assume that appropriate lists will in each such case be displayed by 
the interface's causing the corresponding instantiated instance of the 
execute_in_f uture predicate to hold. 

The system has also managed to prove, under an abductive assumption 
whose justification is payments_ref erred_to_are_f rom_SRI, that the final 
formula is equivalent to the original query. Granted this assumption, the 



user can be informed that the response is complete (cf section 2.5.2 ). 



Chapter 5 

The Reasoning Engine 



CLARE's inference engine is used by several other components. It sup- 
ports proofs from conjunctive contexts when performing translation (cf. sec- 
tion [3.2.1D , and evaluates translated queries; it is also employed to compile 
the lemmas used when generating facts and questions (Chapter ^), and for 
various other tasks during reference resolution which will not concern us 
here. In each case, the basic functionality is some version of the follow- 
ing. We are provided with a Horn-clause theory T, a formula F (which may 
contain free variables x), and a criterion which determines permissible ab- 
ductive assumptions. The task is to find a substitution 8 on x and a set of 
permissible assumptions A such that 

T^(A^9(F)) (5.1) 

or terminate with the information that no such 9 and A exist. This chapter 
describes how the inference functionalities are realized in CLARE as a type 
of Prolog meta-interpreter. Since these have been described many times in 
the literature (e.g. (Sterling and Shapiro, 1986)), we will concentrate on the 
unusual features of the CLARE inference engine. The expositional strategy 
used will be to describe a simplified version of the inference engine, beginning 
with a the basic meta-interpreter for pure Horn-clause theories shown in 



figure 5.1 and adding features as we go along to cover new functionalities. 



5.1 Logical structure 

The basic form of the inference engine is that of a slightly extended Prolog 
meta-interpreter. Superimposed on top of it, there is an iterated-deepening 
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prove (and (L,R)) :~ 
prove (L) , 
prove (R) . 

prove (G) :- 

horn_clause_in_theory (G <- Body) , 
prove (B) . 

prove (G) :- 

unit_clause_in_theory (G) . 



Figure 5.1: Basic Horn-clause interpreter 



A* search strategy. We will only consider the logical aspects of the infer- 
ence engine in this section, postponing discussion of the search strategy until 
section 5.2. There are two important extensions over the standard Prolog 
meta-interpreter: these are to cover abductive proofs and proofs of univer- 
sally quantified implications. We discuss these in Sections |5.1.1| and 5.1.2 
In Section |5.1.3| we briefly consider the treatment of negation. 



5.1.1 Abductive proofs 

We will use the term "abductive proof" in this section to mean construction 
of a proof-tree in which some leaves are undischarged assumptions. CLARE 
performs abductive proofs for two essentially distinct reasons. The first has 
been referred to many times already in chapters [2|, || and ^ when using logic 
to reason about common-sense concepts, such as those expressed in natural 
language, it is frequently necessary to assume background knowledge which 
is not part of the explicit content of the utterance's logical representation. 
In this case, the abductively assumed conditions are normally shown to 
the user in order to check their appropriateness. Abductive proofs are also 
used in order to compile "implicational lemmas", which are utilized by the 
generation component (see Chapter ^) and several other parts of the system 
not described in the thesis. In this mode of operation, the reasoning engine 
is given a goal F containing free variables x and a set of criteria for making 
abductive assumptions; the assumptions may also contain free variables. If 
an abductive proof can be found with assumptions A and a substitution 
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9 for the x, this can be regarded as a strict (non-abductive) proof for the 
Horn-clause 

Vy.(A -> 6(F)) 

where y are the free variables in 6{x). As part of the process of compiling 
a linguistic domain theory, all implicational lemmas of a particular type are 
generated. At present, the criterion used for limiting abductive assumptions 
restricts A to being a set of which all but at most one member are arithmetic 
relation goals (cf section |2.4.2| ). The remaining member of A must be an 
atomic predication whose predicate is a conceptual predicate. The net result 
is to prove an implication of the form 

Arith — > [Conceptual — > G) 

where G is an atomic goal, Conceptual is a conceptual goal, and Arith is 
a conjunction of arithmetical relation goals. These lemmas can be used to 
find quickly the "consequences" of a goal that matches Conceptual (cf |6.3| ). 

Two minor changes are needed to extend a Prolog meta-interpreter to 
allow abductive proofs: another argument is added to the main predicate, 
which passes around a difference-list holding the assumptions, and an extra 
clause is added which allows "proof" of an atomic goal by adding it to the 
assumption-list, if the abductive assumability criteria permit this. The basic 



interpreter, modified in the way described, is shown in figure 5.2 



5.1.2 Proving implications 

We now consider the task of extending the inference engine to be able to 
prove formulas of type 

f orall (Vars , impl (LHS , RHS) ) 

where the variables in Vars occur free in LHS and RHS. Two well-known 
strategies exist for attempting to prove such expressions; they can be proved 
either intensionally or extensionally. Intensional proofs are carried out by 
substituting unique constants for the Vars, assuming LHS, and attempting 
to prove RHS; extensional proofs by listing all values of Vars for which a 
proof of LHS can be found, and for each one ascertaining that a proof of RHS 
exists. The CLARE inference engine can use either strategy. 

To implement the intensional proof strategy it is necessary to add yet 
another argument to the prove predicate in the interpreter, to hold the set 
of assumptions derived from the LHS; it is tempting to try and include them 
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prove (and (L,R) , AssumptionsIn-AssumptionsOut) :- 
prove (L , Assumptionsln-Assumpt ionsNext ) , 
prove (R , AssumptionsNext-AssumptionsDut ) . 

prove (G, AssumptionsIn-AssumptionsOut) : - 
horn_clause_in_theory (G <- Body) , 
prove (Body , AssumptionsIn-AssumptionsOut) . 

prove (G, Assumptionsln-Assumpt ions In) : - 
unit_clause_in_theory (G) . 

prove (G, Assumptions In- [G I As sumptions In] ) : - 
abductively_assumable(G) . 



Figure 5.2: Abductive Horn-clause interpreter 

in the abductive assumption list, but in practice this manoeuvre does not 
seem to simplify matters. The need to take account of possible abductive 
assumptions also introduces some complications in the extensional strat- 
egy, since it is necessary to collect the assumptions used for each separate 
proof of RHS. The skeleton interpreter, modified to allow proof of univer- 
sally quantified implications by the intensional and extensional strategies, is 
presented in figure [5,3| . Here the first clause of form prove (f orall . . .) is 
for the intensional strategy; replace_by_unique_constants is assumed to 
be a predicate which replaces all the variables in its argument by unique 
ground terms. The following clause is for the extensional strategy. Here 
saf e_bagof (X,G,Xs) is like bagof (X,G,Xs) , with the difference that it first 
binds any free variables in G, and succeeds with Xs=[] if there is no proof 
of G; union_n_l (List , Union) takes a list of lists as its first argument and 
returns their union as the second one. 

5.1.3 Proving negated goals 

The inference engine contains no general treatment of negation, but in order 
to deal with cases where Goal is explicitly contradicted by its context it is 
possible to define rules of the form 

neg(Goal) <- Body 
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(All clauses from the interpreter in figure 5. 2 J 



prove (G, Assumptions In-Assumpt ions In, ImplAs sumptions) : - 
member(G, ImplAssumptions) . 

prove (f orall (Vars , impl (LHS , RHS) ) , AssIn-AssOut , ImplAss) : - 
replace_by_unique_constants (Vars) , 

add_implicational_assumptions (LHS , ImplAss , ImplAssl) , 
prove(R, AssIn-AssOut , ImplAssl) . 

prove (f orall (Vars , impl (LHS , RHS) ) , AssIn-AssOut , ImplAss) 
saf e_bagof (environment (Vars , AssDutLef t) , 

prove (LHS , AssIn-AssDutLef t , ImplAss) 
Lef tEnvironmentList) , 
prove_f orall_cases (Lef tEnvironmentList ,Vars~RHS , 

ImplAss ,AssOutList) , 
union_n_l(AssOutList,AssOut) . 

prove_f orall_cases ( [] , _Vars~_RHS , _ImplAss , [] ) . 

prove_f orall_cases ( [EnvFirst | EnvRest] , Right , ImplAss , 

[AssOutFirst | AssOutRest] ) :- 
prove_forall_case (EnvFirst .Right , ImplAss , AssOutFirst) , 
prove_f orall_cases (EnvRest , Right , ImplAss , AssOutRest) . 

prove_f orall_case (environment (VarsLef t , AssOutLef t) , 
Vars'RHS, ImplAss, AssOut) :- 
copy_term( [Vars "RHS, ImplAss] , [Varsl'RHSl , ImplAssl] ) , 
VarsLef t = Varsl, 

prove (RHS1 , AssOutLef t-AssOut , ImplAssl) . 

add_ impl icational_assumpt ions (and(P , Q) , ImplAssIn, ImplAs sOut) 
add_impli cat ional_as sumptions (P, ImplAssIn, ImplAssNext) , 
add_implicational_assumptions (Q, ImplAssNext , ImplAssOut) . 

add_implicational_assumptions(G, ImplAss, [G| ImplAss]) :- 
atomic_goal(G) , ! . 

add_implicational_assumptions (_Other , ImplAss , ImplAss) . 



Figure 5.3: Abductive interpreter for Horn-clauses and implications 
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where Goal is an atomic formula and Body is an arbitrary formula. A rule 
of this type has the content "the negation of Goal is implied by Body", and 
is formally a normal Horn-clause; note that there is no connection, as far 
as the inference engine is concerned, between the goals G and not(G) . Rules 
with negated heads are only invoked to attempt to identify inconsistent uses 



of assumptions (cf. Section 3.5). 



5.2 Search strategies for inference 

In this section we consider the search strategy used in the inference engine, 
which as already stated is an iterated-deepening A* (IDA*) search strategy 
(Korf, 1986, Stickel, 1986); that is, search proceeds by first defining a cost 
limit D, and then performing a depth- first search where each branch is cut 
off when the sum of the cost of goals already processed, together with an 
estimate of the cost of solving pending goals, exceeds D. The cost function 
used at present charges one unit for each rule application, and conservatively 
estimates one unit for each pending goal; as explained in section [D| it is 
possible to define extra costs for abductively assumed goals. The motiva- 
tion for using IDA*, rather than simple depth- first search, is that it avoids 
getting stuck in infinite recursions; it essentially performs the function of 
simulating breadth-first search, and is thus theoretically complete. However, 
experiment quickly shows that infinite recursion still causes severe practical 
difficulties without further elaboration of the method. 

There are basically three problems, which to some extent are related. 
Firstly, it is easy to spend excessive amounts of time in infinite branches 
of the search tree, especially ones resulting from "transitivity" axioms (cf 
(Appelt and Hobbs 90)), and Horn-clause readings of axioms of the form 

(p(X,Y)=p(X,Z))^q(Y,Z) 



(cf Section 4.6.5). The problem becomes even more acute when both "nor- 



mal" and "backward" Horn-clause readings of equivalences are used (cf Sec- 



tion 3.2.3); it is then easy for the inference engine to get into situations where 
it wanders aimlessly around in the search-space, alternately using "normal" 
and "backward" Horn-clause versions of equivalences. Secondly, even when 
infinite branches as such are not a problem, it may be the case that there 
are multiple redundant proofs of a goal. The third problem arises from in- 
efficient ordering of conjunctions. When trying to prove a conjunction, it 
can sometimes be the case that there are many proofs of the first conjunct 
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(which take a correspondingly long time to generate), but that the second 
conjunct can quickly be discovered to have either one or no proofs; in this 
case attempting to prove the conjuncts in a different order can pay dividends. 
The non-obvious aspects of the search strategy, which we will now describe, 
stem from attempts to counteract these problems. We describe them one at 
a time. 

5.2.1 Avoiding infinitely recursive branches 

The approach we currently use to help minimize time spent in infinitely 
recursive branches of the search-tree is based on a standard loop-avoidance 
method. It can be proved that it is sound to cut off search if a goal is 
identical to one of its ancestors. The inference engine uses this criterion, 
both in its simple form and in a "look-ahead" mode: when expanding a 
goal G to a conjunction B\ A B^ . . ., it checks before adding the Bi to the 
stack of pending goals, to make sure that none of them are identical to an 
ancestor. Perhaps surprisingly (since this is a fairly expensive operation), it 
turns out that performing the "look-ahead" check increases efficiency quite 
substantially. 

It would be pleasant if the "identity" condition could be relaxed a little, 
for example by replacing it with a test of unification or subsumption with one 
of the ancestor goals. Unfortunately, it is easy to prove that weakening the 
condition is in general not correct. However, a strong syntactic similarity 
between a goal and an ancestor is often a good heuristic indicator that a 
loop has arisen, and can be taken as a justification for exacting a "penalty", 
causing the cost limit to be reached more quickly. In the current version, the 
penalty is applied if the goal is subsumed by an ancestor, a strategy which 
we have found to work well in practice. The method is sound, since its only 
effect is to devote less effort to search of the affected branches without cutting 
them off completely, and appears rather more general than the approach 
advocated in (Appelt and Hobbs 90), which involves recoding of the meaning 
postulates. 

The loop avoidance method described above is strong enough that it is 
at any rate possible to consider using both forward and backward versions 
of equivalences. Use of the backward versions still slows down the inference 
engine by more than a factor of ten, when it is used to support translation 
with the PRM LDT. For this reason, we decided to remove backward Horn 
clauses. It turned out in practice that the potential inferences lost due to this 
step were fairly unimportant, and that the "inference holes" which appeared 
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could easily be filled by adding a few appropriate hand-coded clauses. 

5.2.2 Avoiding redundant search 

The second problem, that of avoiding redundant recomputation, is currently 
only applied to ground goals, that is goals which contain no uninstantiated 
variables. We have observed in many cases that, without some kind of 
restrictions, a great deal of effort is wasted in producing multiple proofs 
for goals of this kind. Since a proof of a ground goal is basically just a 
"yes" or "no", it is tempting to adjust the backtracking mechanism so as to 
block attempts to find new proofs of ground goals that have already been 
successfully proved. However, this is not quite right; the problem is that 
the ordering of the search-space may mean that the first proof produced is 
an expensive one, which leaves the search process on the verge of exceeding 
the cost limit, and prevents further progress. The correct realization of the 
idea seems rather to be to block retrying of ground goals only if the cost 
of the existing proof falls under a given bound, which we have at present 
arbitrarily fixed as a third of the total cost limit. 

5.2.3 Dynamic re-ordering of conjuncts 

The time taken to find a proof for a conjunctive goal (or to ascertain that 
there is no proof) can often be strongly dependent on the order in which the 
conjuncts are attempted. We have made no attempt to solve this problem 
in its general form, but two special cases are sufficiently important that 
the inference engine needs to take account of them. Suppose first that the 
interpreter is about to attempt to prove the conjunction LAR. If it is the case 
that there is no proof of R, then time lost establishing this can be recovered 
by omitting the attempt to prove L. Thus it can pay to perform "look- 
ahead" and search for goals which can quickly be shown to be unachievable. 
Similarly, if L contains free variables which also occur in R then the time 
needed to find a proof can be reduced if the number of proofs for R is 
substantially less than the number of proofs for L, since instantiating free 
variables nearly always has the function of reducing the number of possible 
proofs. In particular, if it can quickly be shown that there is only one proof 
of R then it is very likely that it will be correct to attempt it first. 
It is possible to include declarations of the form 

quick_f ailure_test (<Goal>) :- <Conds> 
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or 

quick_determinism_test (<Goal>) :- <Conds> 

where <Goal> is an atomic goal and <Conds> an arbitrary Prolog form; the 
intended semantics are that there should be, respectively, no proofs or ex- 
actly one proof of <Goal> if <Conds> hold. For declarations of this kind to 
be useful, <Conds> should be quickly evaluable. In the present version of 
CLARE, instances of <Conds> never do more than check instantiations of 
variables, or attempt to unify them with other terms. Tests for both cases 
are applied when a Horn-clause is used to expand a goal G; after the head 
of the clause has been unified with G, the goals in the body are examined. 
If a quick_f ailure_test succeeds then proof of the whole conjunction fails; 
if a quick_determinism_test succeeds on a subgoal, then that subgoal is 
evaluated first. There are currently about 30 "quick failure and determin- 
ism" declarations, all of them for the "naming" predicates described in sec- 



tion 4.2.1 



5.3 Finding finite proof procedures 

In the final section of this chapter we describe the module responsible for 
searching for finite proof procedures (see also section 2.4.2| ). Since the in- 



ference engine is basically a Prolog meta-interpreter, it is sensitive to the 
ordering of conjuncts: it attempts to prove a goal of the form and(P,Q) by 
first proving P and then proving Q. If P and Q share a free variable X, the 



order can be important. To repeat the example from 2.4.2, if TRANS/3 is 
a database predicate then the strategy "find an X such that X > 100, then 
find values of Y such that TRANS(john, X, Y)" is not a finite strategy; 
however, reversing the order to make the strategy "find X and Y such that 
TRANS(john, X,Y), then determine whether X > 100 holds" is finite. 

The search for finite proof strategies is carried out by another extended 
Prolog meta-interpreter, using an abstract interpretation method. The in- 
formation needed to deal with the base case of attempting to prove an atomic 
goal is provided by declarations of the form 

call_pattern(<Pred>(Argl,Arg2, . . .Argn) , InArgs , OutArgs) 

where <Pred> is a predicate and InArgs and OutArgs are subsets of the 
set {Argl, . . . , Argn}. The intended semantics are that there are finitely 
many proofs of the goal 
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<Pred>(Argl,Arg2, . . .Argn) 

if the variables in InArgs are already instantiated, and that each of them will 
result in the arguments OutArgs becoming instantiated. The basic structure 



of the interpreter is shown in figure 5.4; only the clauses for conjunctive 



and atomic goals are displayed. In the implemented interpreter, there is 
a clause for each logical operator of the TRL language. The central idea 
is to rearrange the expression by using an abstract version of the Prolog 
"freeze" or delayed-goal primitive. The arguments of the main predicates 
rearrangeO and rearrange 1 are 

rearrangeO/ 1 (Original , Rearranged , Eval , Frozen , Done) 

where 

Original is the original expression. 
Rearranged is the rearranged expression. 

Eval is a copy of Original used to keep track of the variables currently 
instantiated in the abstract interpretation. 

Frozen is a difference-list of delayed goals, i.e. goals which were insuffi- 
ciently instantiated to be executed when first called. 

Done is a difference-list that keeps track of progress made in evaluating goals, 
to prevent infinite postponement of goal execution. 

The two predicates call each other recursively, with rearrangeO calling re- 
arrange 1 and then trying to "thaw" any frozen goals that may have been 
created. Note the special treatment of equality goals: if Eval is an equality, 
its arguments are unified if possible. 
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rearrange (01dForm,NewForm) :- 
copy_term(01dForm,EvalForm) , 

rearrangeO (01dForm,NewForm,EvalForm, []-[],[]-_), ! . 

rearrangeO (01d,New,Eval ,FrozenI-FrozenO ,DoneI-DoneD) : - 
rearrangel (Old , NewO , Eval , Frozenl-FrozenN , Donel-DoneN) , 
thaw (NewO , New , FrozenN-FrozenO , DoneN-DoneO) . 

rearrangel (and (L01d,R01d) ,and(LNew,RNew) ,and(L,R) , 
Frozenln-FrozenOut ,DoneIn-DoneOut) :- !, 
rearrangeO (LOld , LNew , L , Frozenln-FrozenNext , Donel-DoneN) , 
rearrangeO (ROld , RNew , R , FrozenNext-FrozenOut , DoneN-DoneO) . 

rearrangel (OldG, 01dG,G, Frozen-Frozen, Done- [goal_done | Done] ) : - 
abstract_call(G) , ! . 

rearrangel (OldG, true, G, Frozen- [f rozen(G, OldG) |Frozen] ,D-D) . 

thaw (Form, Form, []-[], Done-Done) :- !. 
thaw (Form , DutForm , 

[f rozen(FrozenEval , FrozenOld) I FrozenNext] -FrozenOut , 
Donel-DoneO) :- 

rearrangel (FrozenOld, FrozenNew,FrozenEval, []-[],[]-[_!_]),!, 
thaw (and (Form, FrozenNew) , OutForm, FrozenNext -FrozenOut , 
[goal_done | Donel] -DoneO) . 
thaw (Form , OutForm , 

[FrozenFirst | FrozenNext] - [FrozenFirst | FrozenOutRest] , 
Donel-DoneO) :- 
thaw (Form , OutForm , FrozenNext-FrozenOutRest , Donel-DoneO) . 

abstract_call(X=Y) :- 

X = Y, ! . 
abstract_call(_X=_Y) :- !. 
abstract_call (G) :- 

call_pattern(G,InArgs,OutArgs) , 

is_instantiated(InArgs) , 

make_instantiated(OutArgs) . 



Figure 5.4: Interpreter for finding finite proof strategies 
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Chapter 6 

Generation of Utterances 



6.1 Introduction 

So far, we have concentrated on interfacing functionalities which involve 
translating from natural language primitives into database primitives. This 
chapter describes a simple method that has been implemented in CLARE to 
handle translation in the reverse direction; the input is expressed in terms 
meaningful to the database, and the output is in the form of natural language 
utterances. We will as usual mainly be concerned with the part of the 
translation process that involves inferences, but to put the work in its proper 
context we first briefly discuss CLARE's overall strategy with regard to 
generation. 

Recall that CLARE has two main abstract levels of representation: Quasi 
Logical Form (QLF) and TRL. QLF is the representation that is output by 
the first, compositional, phase of semantic analysis. The rules used to relate 
QLFs to surface strings are coded entirely in terms of unification, and are 
both in theory and in practice fully reversible. Generation of surface form 
from QLF is performed by the Semantic Head-Driven generation algorithm 
(Shieber et al 1990), and will not be discussed further here; we will instead 
concentrate on the problem of producing suitable QLF representations from 
database input, expressed in terms of TRL formulas. We will consider gen- 



eration of both assertions and questions, as described in Section [2.5.5| . As- 
sertions will be generated to describe complete database records; questions 
to ask for values of unfilled fields in incomplete records. 

To understand the problems involved in synthesizing an appropriate QLF 
representation for a TRL formula, it will be helpful to begin by considering it 
as the inverse of the analysis process, which has QLF as input and database 
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TRL as output. As described in Section |1.2| , the analysis process has two 
main phases: the resolution phase, in which referentially vague expressions 
are replaced by concrete values; and the translation phase, in which linguistic 
predicates are translated into database predicates. Both of these phases need 
to be inverted. The reason why this task is non-trivial is that a good deal 
of information pertaining to surface linguistic form is lost in the transition 
from QLF to TRL. There are two main problems. 

The first is that the resolution phase can in general be arbitrarily non- 
deterministic in the reverse direction. For example, a given definite NP will 
normally only be able to refer to a small number of possible domain objects; 
conversely, however, there are a potentially infinite number of definite noun- 
phrases that can be used to refer to a given domain object. The generation 
of definite descriptions is a major research topic in its own right, and in order 
to keep the focus on our primary area of concern, the translation problem, 
we restrict ourselves by only considering resolution rules that are determin- 
istic in the reverse direction. Typical examples of such rules are those which 
resolve proper name expressions, numbers and date expressions. In the re- 
verse (TRL to QLF) direction, these take as input a TRL term representing 
a typed object, number, or date, and return a QLF term construct which 
encodes the surface semantic structure of an appropriate noun-phrase. We 
will see examples of use of these rules later in the chapter. 

The second problem is caused by the loss of hierarchical structure in- 
volved in the transition from QLF to TRL. For example, an NP modified by 
a relative clause will at QLF level contain the contribution of the relative 
as a distinct sub-form. After conversion to TRL, however, the structure is 
"flattened"; the head-noun and all its modifiers, including the relative, will 
be at the same level. Our initial implementation solves the second problem 
by tightly limiting the range of possible QLFs that can be produced; the 
process of producing QLF from TRL is not free, but is rather constrained to 
follow one of a set of "template" rules. These templates are automatically 
produced by generalizing specific training examples, using a variant of the 
so-called "case-based learning" method. The learning procedure is described 
in Section |6.2| . It produces rules of the approximate form 

qlf _f or_trl(<QLF>) :- <Body> 

where <Body> is a set of TRL goals. (We refer to these as TRL description 
generation rules, or simply TRL generation rules.) The goals in <Body> can 
be of several different types: they include the component conjuncts in the 
TRL form that is being generating from, and conditions constraining terms 
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in <QLF> to refer to TRL constants. Examples of learned TRL description 
rules are given in the next section. 

The set of TRL description rules is not complete; a QLF can be produced 
only if it is of the same form as one of the training examples. They are not 
necessarily guaranteed to be sound either, though we have not in practice 
observed any unsound rules to have been inferred by the process. The status 
of the rules is thus that of generation heuristics, induced by analysis of 
specific examples. To check the soundness of a rule, it necessary to make 
sure that the original TRL can be recovered from the proposed QLF. 

Loss of completeness is not necessarily important, since there is no need 
to be able to produce every way of expressing something. Indeed, every- 
day experience suggests that people generally make use of an array of stock 
phrases when expressing themselves; there is no obvious reason to believe 
that one has to have a general mechanism for generation at this level. The 
unsoundness of the method is more significant, since checking correctness 
is moderately expensive. One way to attack this problem might be to at- 
tempt to infer rules using the Explanation-Based Learning method (Hirsh 
1987, Rayner 1988); the application of reference resolution methods would 
be conditions on the inferred rules. In the rest of this chapter we describe 
in more detail TRL generation as implemented in CLARE. 

6.2 Learning case-based description rules 

The learning method used for acquiring TRL description rules is extremely 
simple, and is perhaps best introduced by an example. Suppose that the 
training example is the sentence 

John is a dog. 

uttered in a context in which "John" can be used to refer to the entity j ohnl. 
This produces the QLF 

[del, 

form(verb(pres,no,no,no,y) , 
A, 
B~ 
[B, 
[be, 
A, 

term (proper _name (tpc) , C,D~ [name_of ,D, John] ,E,F) , 
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G~ [eq,G,term(q(H,a,sing) ,1, J" [dogl, J] ,K,L)]]] , 
M)] 

(the details of the QLF representation are not interesting). After resolution 
and simplification, this produces the TRL form 

dogl(johnl) 

The idea is to generalize the training sentence by looking for correspon- 
dences between the QLF and the TRL representations, and hypothesizing 
that they are instances of a general rule. In our example, there are two such 
correspondences. 

1. The predicate symbol dogl occurs in both QLF and TRL. 

2. The QLF representation contains the QLF term 

term(proper_name (tpc) ,C,D~ [name_of , D , John] ,E,F) 

and the TRL representation contains the TRL term johnl, and there 
is a deterministically reversible resolution rule which makes the TRL 
term the referent of the QLF term. 

In order to generalize the example, we hypothesize that the connection be- 
tween the QLF and TRL representations depends on the linguistic properties 
associated with the predicate dogl, and the referential connection between 
the two terms. We make the first of these precise by using the predicate 
genpred, which links a predicate symbol to the lexicon entries in which it 
appears. Here, the relevant clause of genpred is 

genpred (dogl , ([dogl,_] ,nbar (_,_))) 

- that is, dogl is a one-place predicate and a common noun (nbar) sense. 
Our precise hypothesis with regard to replacing dogl is then that the infor- 
mation about it genpred constitutes a sufficiently detailed description of its 
properties that any other predicate with a similar entry would be processed 
in the same way. So we are guessing, for example, that in a context where 
"Mary" can be used to refer to the entity maryl, the TRL 

catl (maryl) 

could have been produced from the QLF 
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[del, 

f orm(verb(pres ,no ,no ,no ,y) , 
A, 
B~ 
[B, 
[be, 
A, 

term(proper_name(tpc) ,C,D~ [name_of ,D,Mary] ,E,F) , 
G" [eq,G,term(q(H,a,sing) , I, J~ [catl, J] ,K,L)]]] , 
M)] 

our justification being that catl has a similar genpred entry, i.e. 

genpred(catl , ( [catl , _] ,nbar (_ , _) ) ) 

and that there is a reversible resolution rule which given the atom maryl 
can find out that the QLF expression 

term(proper_name(tpc) ,C,D~ [name_of ,D,Mary] ,E,F) 

would refer to it. In the general case, our heuristic rule will be to guess that 

[del, 

f orm(verb(pres,no,no,no,y) , 
A, 
B~ 
[B, 
[be, 
A, 

<Term> , 

G" [eq,G,term(q(H,a,sing) ,1, J" [<PredAtom> , J] ,K,L)]]] , 
M)] 

is a QLF from which it would be possible to derive the TRL form 

<PredAtom> (<Ref >) 

under the assumptions that <PredAtom> is a atom, <Term> is a term, the 
genpred entry for <PredAtom> is 

genpred (<PredAtom> , ( [<PredAtom> , _] ,nbar (_ , _) ) ) 

and <Ref > is the referent of <Term>. This information is what is encoded in 
the induced rule, 
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trl_gen( [del , 

f orm(verb(pres,no,no,no,y) ,A, 
B~[B, [be, 
A, 

Term, 

C~ [eq,C,term(q(_,a,sing) ,_, 

D-[Pred,D] ,_,_)]]], 

_)], 
[Pred.Ref] , 

[entity_ref _term(Ref ,Term) , 
trlgoaK [Pred.Ref] , 

genpred(Pred, (E~ [Pred.E] ,nbar (_,_))) )] ) 

The three arguments to the rule are, in turn, the generalized QLF; the asso- 
ciated generalized TRL representation; and the conditions of applicability. 
The rule is capable of producing QLFs for sentences of the form 

(NP) is a/an (Noun). 

where (NP) is any referring expression for which there is a reversible resolu- 
tion method. This includes NPs like "John", "Mary (the employee)", "1990 
(the year)" and "1/1/89 (the day)". 

6.3 Description of database entities 

We now show how CLARE can use the TRL description rules to produce 
sentences describing database objects. This functionality is in the imple- 
mented system linked to the semantics of English verbs like "talk about 
(something)" and "tell (someone) about (something)". Thus for example 
processing of a sentence such as 

Talk about Peter Piper. 

will produces a call to describe the conceptual object referred to by the 
expression Peter Piper, namely 

employeel#' Peter Piper' 



The description module is passed the conceptual object X that is to be 
described, and begins by finding all conceptual goals Q (see section 4.2 ) 
which have the property that at least one argument position is filled by 
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an occurrence of X. This provides an abstract "conceptual-level" summary 
of "what the database knows about X v . The main part of the processing 
is then carried out by two sub- modules, the utterance synthesizer and the 
utterance filter, which are called in alternation. The synthesizer uses the TRL 
description rules to attempt to find new utterances whose truth-conditions 
are implies by some Cj. After each such utterance is found, but before it 
is displayed, the utterance filter is called into play to determine whether or 
not the new utterance should be shown to the user, and if so whether any 
more utterances need be searched for. We illustrate the behaviour of the 
description module by sketching the course of processing for the example 
given immediately above. The first C{ found is the predication (CI) 

employee (organizationl#sri,employeel#' Peter Piper' ,m,y) (CI) 

which conveys the information that the employee Peter Piper is a employee 
at the organization SRI, is of sex m (for "Man"), and has a car (y as opposed 
to n). 

The utterance synthesizer is called first. When passed a conceptual goal 
Cj, the synthesizer begins by computing the set of goals logically implied 
by the union of C{ with the current linguistic domain theory excluding the 
database: the result is then uses as input to the learned TRL description 
rules. The efficiency of the process is increased by pre-compiling the set of 
consequences of a generic representative of each class of tuple, and caching 
the results in the form of "implicational lemmas" . The relevant lemmas are 
of the form 

Conditions -> (<C> -> <L>) 

where <C> is a conceptual goal matching Cj, Conditions is a conjunction of 
evaluable predicates, and <L> is an atomic goal whose predicate is a linguistic 
predicate (cf. section |5.1.ip . Continuing with the example, synthesis from 
the goal (CI) proceeds as follows. First the TRL lemmas are used to find 
the set of consequences of (CI). When the concrete values for the relevant 
instances have been instantiated, the result is a list which includes the goals 

carl (skl2(employeel# 'Peter Piper' ) ) 
navel (skl3(employeel# 'Peter Piper' ) , 

employeel#' Peter Piper', 

skl2(employeel#' Peter Piper')), 
malel (employeel# ' Peter Piper'), 
manl (employeel# ' Peter Piper'), 
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name_ofl( 'Peter Piper' ,employeel#' Peter Piper'))), 

sex_of 1 (Male , employeel# ' Peter Piper ' ) , 

personl (employeel# ' Peter Piper ' ) , 

at 1( employee 1#' Peter Piper' ,organizationl#sri) , 

employeel (employeel# ' Peter Piper ' ) , 

Here, skl2(X) and skl3(X) are Skolem functions representing, respectively, 
the car employee X has (if such an object exists), and the event of his or her 
having it. It is now possible to attempt to apply learned description rules, 
some of which succeed. For example, the first two "consequence" goals, 

carl (skl2(employeel#' Peter Piper' ) ) 
navel (skl3(employeel#' Peter Piper' ) , 

employeel* 'Peter Piper' , 

skl2 (employeel* 'Peter Piper')), 

licence an application of the rule generalized from 
John loves a cat. 

with employeel#Peter Piper substituting johnl, navel substituting lovel 
and carl substituting catl in the conditions. Now the noun phrase Peter 
Piper (the employee) can be produced as an NP whose referent is employee l#Peter 
Piper; the relevant resolution rule is reversible, as there is sufficient structure 
in the typed variable. Synthesis proceeds from the QLF produced, yielding 
the sentence 

Peter Piper (the employee) has a car. 

Before the sentence is displayed, the utterance filter is called. The filter keeps 
track of the combined propositional content of the sentences so far uttered 
when describing the current tuple, which is stored as a global variable P ^- 
(Initially, the value of P G ^ is true). When the filter is passed a new candidate 
utterance with propositional content P, it first ascertains whether or not P 
is implied by P id- If this is the case, it returns the information that the new 
utterance is redundant and need not be displayed. If not, it displays the new 
utterance, and updates the combined propositional content to P Q id A P. It 
then checks again to find out whether P ^ A P is equivalent to the current 
tuple. If so, no more utterances need to be generated. 

The expression representing the content is first transformed if necessary 
by replacing Skolem functions with existentially quantified variables and 
then translated into conceptual form. Thus the propositional content of the 
first utterance is originally 
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and (carl (skl2 ( employee 1#' Peter Piper' ) ) , 
havel (skl3(employeel#' Peter Piper') , 
employeel#' Peter Piper', 
skl2(employeel#'Peter Piper'))) 

After replacement of Skolem functions by existentially quantified variables, 
this becomes 

exists ( [X,Y] , 
and(carl(X) , 

have 1(Y, employee 1#' Peter Piper', X))) (C2) 
and after translation, 
exists ( [X] , 

employee (organizationl#sri,employeel#' Peter Piper' ,X,y) (C3) 

Translating (C2) into the canonical form (C3) makes it simple to ascertain 
that the tuple has so far not been completely described, by comparing (C3) 
and the original tuple (CI). On the next cycle, the compiled consequence 
goal 

manl (employeel# 'Peter Piper') 

is used to generate the sentence 

Peter Piper ( the employee ) is a man. 

The conjunction of (C3) and the propositional content of the second sentence 
now however translates to (CI) , so the filter can return with the information 
that the tuple has been completely described. 

For tuples whose structure is more complex, the filter leads to a very 
substantial reduction in the verbosity of the output produced by the de- 
scription module. For example, when generating from a project tuple the 
output produced is something like the following 

CLARE (the project) 's end date is 19/11/1992 (the day). 
CLARE (the project) 's number is 8468. 

CLARE (the project) 's start date is 20/11/1989 (the day). 
With the utterance filter disabled, the output becomes 
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CLARE (the project) 's end date is 19/11/1992 (the day). 
CLARE (the project)' s number is 8468. 

CLARE (the project)^ start date is 20/11/1989 (the day). 
CLARE (the project)'s account is account 8468. 
CLARE (the project) 's project number is 8468. 
CLARE (the project)' s account number is 8468. 
19/11/1992 (the day) is an end date. 
8468 is a number. 

20/11/1989 (the day) is a start date, 
account 8468 is an account. 
CLARE (the project) is a project. 
8468 is a project number. 
8468 is an account number. 

CLARE (the project) began on 20/11/1989 (the day) . 
CLARE (the project) ended on 19/11/1992 (the day) . 
CLARE (the project) finished on 19/11/1992 (the day). 
CLARE (the project) started on 20/11/1989 (the day) . 
CLARE (the project) began. 
CLARE (the project) ended. 
CLARE (the project) finished. 
CLARE (the project) started. 

As can been seen, the niter's simple uniform mechanism manages to elimi- 
nate several different kinds of excess verbosity, some of which are not obvi- 
ously redundant and require non-trivial inference to detect. 



6.4 Generating questions 

It is also possible, using the methods we have just described, to generate 
questions. The module in CLARE responsible for doing this is invoked 
by the top-level CLARE command . ask: if some incomplete tuples have 
been created by processing assertions (see sections 2.5.3| and |3.6.3 ), CLARE 



will respond to . ask by entering a loop where it poses questions to the user 
intended to elucidate the information necessary to fill the unknown argument 
positions. This can involve generation of both Y-N and WH- questions. We 
begin by giving an example dialogue: utterances by CLARE and the user 
are prefixed by clare> and user> respectively, and comments are in normal 
font. 



user> ARLA is a project. 
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The user inputs a declarative statement. After processing it, CLARE has 
an incomplete project record. 

user> .ask 

The user invokes the question-asking module to fill the unspecified fields in 
the record. 

clare> what is ARLA (the project) 's account? 

CLARE asks a question to find out the filler of the "account" field in the 
record, and hands control back to the user to get the answer. 

user> 1234. 

The user answers. The utterance is processed by CLARE in the normal way, 
which involves syntactic and semantic analysis, followed by ellipsis resolution 
in the context of the previous question. 

clare> account 1234 is ARLA (the project) 's account. 

CLARE prints out a paraphrase showing the result of performing resolution, 
to keep the user informed. It then translates the result in the usual way, 



merging it with the previous one as described in section 3.6.3 . 

clare> what is ARLA (the project) 's start date? 

CLARE asks another question, this time to find out the project's start date. 
Processing is as before. 

user> 1/4/93. 

clare> 1/4/1993 (the day) is ARLA (the project) 's start date. 
clare> what is ARLA (the project) 's end date? 

Another question from CLARE; this time, the user replies with a sentence. 
Processing is still the same as usual. 

user> ARLA will end on 1/4/96. 

When this sentence has been processed, CLARE has successfully filled all 
the fields in the tuple. 

The range of questions currently handled is limited to Y-N questions 
whose propositional content is an existentially quantified conjunction, and 
WH-questions whose propositional content is a lambda-bound existentially 
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quantified conjunction. For questions of these types, we can acquire case- 



based rules by a slight extension of the methods described in section the 
only extra point is that it is necessary to store the lambda-bound variable 
for a WH-question. Thus for example the rule induced from the training 
sentence 

Who loves Mary? 

is 

trl_gen( [whq, 

f orm(verb(pres,no,no,no,y) , 
A, 

B" [B, [C,A,term(q(tpc,wh,_) ,_, 

D" [personal, D] ,_,_) ,E]] ,_)] , 

F~exists ( [G] , 

and ( [personal ,F] , 
[C.G.F.H]))) , 
[entity_ref _term(H,E) , 
personal (I) , 
trlgoal([C,_,I,H] , 

genpred(C, (f orm(_,verb(_, _,_,_,_) , 

J,K~[K, [C,J,_, J] ,_) , 
v(_, _))))] , 

[I]) 

where the fourth argument [I] to trl_gen is the list of lambda-bound vari- 
ables in the conditions; note that the second argument, the propositional 
content, is already a lambda-bound form. We now describe how rules of this 
kind can be used. 

Let us begin by supposing that we have a conceptual goal C, in which 
some argument X is so far uninstantiated. There are two obvious strategies 
to use when trying to find a filler for X. The first is to attempt to frame a 
WH-question whose propositional content is equivalent to XX. C; the second 
is to substitute some plausible value a for X in C, and then try to find a 
Y-N question whose content is equivalent to C[X/a\. CLARE can use either 
strategy, choosing according to the nature of the argument position. If it is 
an argument that has to be filled by one of a known finite set of possible 
code values, it tries the second strategy; otherwise, it uses the first one. 

For both strategies, the major difference compared to generating asser- 
tions is that what is required is an utterance whose propositional content is 
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equivalent to that of the question, not implied by it. We will refer to the 
initial expression, either XX. C or C[X/a] as the case may be, as the abstract 
question; we can reduce the two cases to one by considering abstract ques- 
tions as forms bound by a set of lambdas, where the set is empty for Y-N 
questions and non-empty for WH-questions. 

Suppose then that the abstract question is XX. C where X is a vector of 
variables. Generation proceeds as follows. We try to find a description rule 
R, generalized from a question, for which the set of lambda-bound variables 
is Y, the conditions are Conds, the propositional content is XY.Pr, and the 
following hold: 

1. The cardinalities of X and Y are equal. 

2. If a is a set of unique constants with the same cardinality as X and Y, 
then Conds[Y /a] is implied by C[X/a\. 

3. P R [Y/a] implies C[X/a] 

If these conditions are met, then the propositional content of R is equivalent 
to that of XX. C. The conditions are phased the way they are so as to allow 
use of the techniques presented in section |6l| thus the second condition is 
satisfied using the compiled TRL lemmas, and the third one with essentially 
the same mechanism as that used by the "utterance filter" described at the 
end of the last section. 
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Chapter 7 

Conclusions 



7.1 Summary 

We will now pull the threads together and summarize the main arguments of 
the thesis. The fundamental idea has been to provide a formal account of how 
natural language utterances can be related to the contents of databases. We 
have reduced this to a logical problem by assuming that both databases and 
natural language utterances can be expressed in logical terms. The databases 
present no problem; to deal with the language, we have assumed the existence 
of a "natural language engine" , which can mediate between surface linguistic 
expressions and their representations as "literal logical forms" . The problem 
now became one of converting between two types of logical formulas, one 
relating to language and one relating to databases. In Chapter ||, we showed 
that several different types of interface functionality can be reduced to the 
same common form: we are given a formula F source , a background theory 
r, and criteria which permit the making of certain assumptions. We are 
asked to find a formula Ft arge t, fulfilling certain restrictions, and permissible 
assumptions A, such that 

ruA=J> {Fu n g = Fdb) (7.1) 

One important technical device used was to give the database predicates a 
"trivial" semantics, referring only to the existence of database tuples and not 



to objects in the exterior world. In Section 2.6, we showed how this makes it 
possible to side-step in a simple way the difficulties associated with use of the 
Closed World Assumption, in effect allowing the CWA to be "relativized" 
by the domain theory V. 

The next two chapters addressed two interlinked questions: 
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1. Can we construct suitable theories T, that make it possible to solve 
inference problems of type ( |7. 1| ) with reasonable efficiency? 

2. If so, how are these inference problems solved? 

Answering the two questions just posed in reverse order, we first described in 
Chapter || an inference process, Abductive Equivalential Translation (AET), 
which can be used in conjunction with a domain theory consisting of directed 
conditional equivalences and Horn-clauses. AET is sound but not complete; 
its strength is that it has an efficient and easily comprehensible precedural 
model, which allows equivalential theories to be constructed and debugged 
in much the same way as Prolog programs. A few initial examples were 
presented, showing in particular how AET is powerful enough to provide an 
elegant and natural solution to the well-known "Doctor on Board" problem. 
The AET process relies on having an extended Horn-clause inference engine, 
which was described in Chapter [|. 

In Chapter ||, we then went on to show how equivalential theories of 
the type described in the previous chapter could be constructed to solve the 
original problem of relating linguistic and database predicates. We described 
an example theory, which relates a fairly wide range of linguistic constructs 
to the database relations of a real projects and payments database. The key 
idea was to structure the theory in a modular way that allows the linguistic 
predicates to be translated into forms successively "nearer" to the database 
relations. In particular, we argued that it is useful to funnel translation 
through so-called "conceptual" predicates; each database predicate D cor- 
responds to one conceptual predicate, which roughly contains the union of 
the information in D and the lingustic predicates that translate into it. We 
also show how introduction of conceptual predicates makes it possible for 
translation to deal with contingent completeness of database information, 
in particular the common constraint that records are only available for a 
limited period. 

Nearly all the previous discussion focussed on translation of linguistic 
predicates into database predicates. Chapter || considered the reverse prob- 
lem of deriving language from database. A simple method was introduced, 
that extracted "templates" from typical examples and could use them to 
generate both descriptions of complete database records and questions ask- 
ing for values of unfilled fields in incomplete ones. The method used AET 
to provide a "filter" which limits the verbosity of descriptions of complete 
tuples, and checks the validity of proposed questions. 
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7.2 Further directions 

7.2.1 Using AET in other domains 

This thesis has reported in detail how a non-trivial natural-language interface 
was successfully implemented using AET. Every effort was made to employ 
methods that would be as general as possible, but the fact remains that 
one swallow does not make a summer: AET needs to be used more before 
its merits can be properly evaluated. It is thus pleasant to be able to say 
that a second AET application, a CLARE interface to the AUTOROUTE 
route-finding package, has now been constructed. This is being reported 
elsewhere (Lewin et al 1993). It is particularly gratifying that nearly all the 
work was carried out by project personnel (primarily Ian Lewin) who had 
not participated in the development of the PRM application. Two swallows 
do not make a summer either, but one can at any rate say that the swallow 
population seems to be increasing. 



7.2.2 Making the AET process symmetrical 

One unfortunate shortcoming of the work reported here is the lack of symme- 
try between the roles played by equivalences in the analysis and generation 
processes. Since equivalences are by their nature symmetrical, it seems quite 
reasonable to expect that the part of the generation process which is con- 
cerned with inference could be formulated more directly in terms of AET. 

In this context, I would like to make it clear that the treatment of gener- 
ation described in Chapter [6| should not be regarded as more than a stopgap; 
in this section, I will sketch how a more satisfying solution could be achieved. 



Recall from Section 2.4 the key notion of "effective translation", which was 
used to formalize the analysis tasks. Here, we were given a linguistic formula 
Fsource- then the condition for F tar get to be an effective translation of 

Fsource 

was that there existed a set of abductive assumptions A such that 

r U A (F source = Fi ar g e i) (7.2) 

and 

• Each assumption in A is acceptable in the context in which it is made. 

• There is a finite proof procedure for determining the truth of Ftarget- 

The symmetrical concept in the generation direction could be called a "lin- 
gustically realizable translation" . So this time we axe given an F source which 
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is a formula expressed in terms of database predicates: then F tar get is a 
linguistically realizable translation of F source if there is a set of abductive 
assumptions A such that 

r U A => (F source = Ftarget) (?-3) 

and 

• Each assumption in A is acceptable in the context in which it is made. 

• There is a linguistic utterance whose "literal" logical denotation is 

Ftarget ■ 

The AET process would be used in the database to language direction to 
derive possible candidates for F target ; these would be analyzed further to 
discover if they could be realized as denotations of utterances. 

It has been possible, using AET in the language to database direction, to 
make the translation process deterministic: this is justifiable on the grounds 
that database representation is a canonical form. The main technical prob- 
lem involved in implementing the proposed scheme is that the AET process 
in the database to language direction would have to be non-deterministic, 
since linguistic representations are not canonical. For this reason, we did not 
attempt to implement reverse AET in the CLARE project. It seems to me, 
however, that the obstacles posed are by no means insuperable, and that it 
would be extremely interesting to investigate the "reverse translation" idea 
more thoroughly. 



7.2.3 Goal-directed reasoning about acquisition of knowledge 

It is worth noting that the formalization of "knowing wh..." described in Sec- 



tion 



2.5.4 can easily be extended into a formalization of "finding out wh...". 
This can be done in several ways: the simplest is to allow the conditions on 
certain equivalences to be contingent on executable assumptions, assump- 
tions which will be true if appropriate perceptual actions are carried out. 
We illustrate with a sketch of the standard example, "finding out someone's 
telephone number" (cf e.g. (McCarthy 1977), (Moore 1985)). 

Simplifying as much as possible (and side-stepping some of the temporal 
reasoning issues without comment), we start by letting T be the background 
theory as usual. We assume we have an "open" predicate 



phonejno(Name, Number, T) 



7.2. FURTHER DIRECTIONS 



135 



with the intended semantics "the phone number of the person called Name 
is Number at time T" . We also have a "closed" predicate, 

REC .PHONE _NO(Name, Number, T) 

whose semantics are "the phone number of the person called Name is Number 
at time T, and this is recorded in my database at time T". Now suppose 
we want to reason about how we might find out Mary's phone number, 
in other words arrange for it to be present in the database. We formalize 
this as requiring a formula F d j, expressed in terms of the database predicate 
REC _PHONE_NO, a time Tdone, and a set of assumptions A corresponding 
to actions that I can carry out, such that 

T U {A, finish Jime(T done )} => 
{(3N.phone_no(mary', N, T done )) = F db ) (7.4) 

where T done represents a time at which the information has been added to 
the database. Including the goal finish J,ime{T done ) on the left-hand side is 
convenient for reasons that will shortly become apparent. 

The following formula expresses the fact that the phone number of the 
person called Name is recorded in my database after I have executed the 
action of looking up Name in the telephone directory 

execute(directoryJookjup(Name),Ti) A befor e' (T±, T%) — > 
(phone_no(Name, N, T 2 ) = REC.PHONE_NO(Name, N, T 2 )) (7.5) 

Lastly, we have to specify assumability conditions. We allow goals of the 
form 

execute(Action, Time) 

to be assumed if Time is in the future and Action is a ground action term. 
We also allow goals of the form 

before' \T U T 2 ) 

to be assumed if T\ is the time of an executed action, and 

f inishJcime^T'i) 

holds, on the grounds that we are at liberty to choose a finish time that 
occurs after all the necessary actions have been completed. 
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By performing normal AET, it follows (we omit the details) that a solu- 
tion to [F!4| exists, where is 

3Ni . REC-PHONE_NO (mary , N h T done ) 

and A (the set of assumptions) is, for some Ti ookup 

{execute(look_up_no(mary'),Ti ookup ), before' (T lookup , T done )} 

In other words, I will know what Mary's number is at any moment after the 
time when I perform the operation of looking it up. The significant thing 
about this example, compared e.g. to the account in (Moore 1985), is that 
the process of reasoning about knowledge acquisition is carried out in a goal- 
directed way that is compatible with normal AI planning methods. I think 
that this is an interesting idea to explore further. 
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Appendix A 

The semantics of questions 



This appendix summarizes the theory of question semantics used through- 
out the thesis. There are two main points. First, we distinguish between 
questions and question utterances; this is not an idea that most linguists will 
find controversial, though non-linguists will perhaps feel it needs some expa- 
nation. Briefly, then, questions are a type of linguistic construction that can 
occur either alone or embedded in other constructions. The only question- 
embedding construction that is considered in any detail in the main body 
of the thesis is "know Q\ with Q a question (see Section 2.5.4D ; typical 
examples, with the embedded questions italicized, might be 



(Ql) Do you know which employees work on each project? 

(Q2) Do you know whether any payments were made after 1/1/92? 

The embedded question in (Ql) is considered to be Which employees work 
on each project?, and in (Q2) Was any payment made after 1/1/92?. 

When questions stand on their own, we call them question utterances. A 
question utterance is considered to be a command to answer the question 
in some appropriate way. Now when assigning semantics to questions, we 
will require that embedded questions and question utterances be treated 
uniformly. A given question, Q, will have some semantic value, Q'. We 
thus require that the semantic value of Q used as a question-utterance be a 
function of Q' , and also that the semantic value of a construction embedding 
Q be a function of Q'. For our present purposes, we can be even more specific: 
we demand that 
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1. The semantics of constructions of type "X knows Q" should be schemat- 
ically 

know'(x', Q') 

In practice, we will only be interested in what the system knows, and 
we will abbreviate 

know' (system' , Q') 

to 

kw{Q') 

2. The semantics of Q used as a question utterance should be schemati- 
cally 

question-answer ed(Q') 

This is interpreted as a goal that will be true if an action is carried out 
appropriate for answering Q. 

We in discuss appropriate semantics for the operators question-answered 
and kw in Sections 2.5.1 , 2.5.2 and [2.5.4 . 



The remaining point to consider is how to assign appropriate semantics 
to the questions themselves. Here, we will adopt a minimal proposal, which 
as far as we know was originally suggested by Bennett (1979); we try to 
abstract away as much as possible from the details of any specific semantic 
theory. The proposal is as follows: 

1. If Q is a Y-N question corresponding to a declarative sentence D (i.e. 
Q is the question that asks whether or not D is true), then we take its 
semantic value to be that same as that of D. 

2. If Q is a WH-question, which can be read as asking which objects stand 
in a given relationship R, then the semantic value of Q is R. 

The Y-N question case should be clear, but the WH-question case needs 
some further explanation. Usually, there will be only one WH-element, and 
the question can be read as asking for objects with a certain property. Thus 
for example consider the questions (Q3)-(Q5): 

(Q3) Who worked on the CLARE project? 

(Q4) When did the CLARE project finish? 



(Q5) Which projects started during 1990? 
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Here, the semantic value of (Q3) is a property that holds of people who 
worked on the CLARE project; the semantic value of (Q4) is a property 
that holds of dates when the CLARE project finished; and the semantic 
value of (Q5) is a property holding of projects which started during 1990. 
The semantic value of a property can most simply be represented as a A- 
abstraction: if we allow this, the semantic values of (Q3)-(Q5) are roughly 
those shown in (|PD-(|OD: 

XX.person'(X) Awork-on'(X,clare) (A.l) 
XD3E.date{D) A finish' (E, dare) A date.of{E, D) (A.2) 

XP3E.project(P) A start' (E, P) A during' {E, 1990) (A.3) 

If there are (either explicitly or implicitly) several question-elements, then 
the semantic value of the question becomes a relation, as in (Q6) and (Q7): 

(Q6) Who works on which project? 

(Q7) When did each project start? 

which receive the semantic values shown in ( |A.4j ) and ( |A.5| ): 

XXXY.person'(X) A project' (Y) A work_on'(X, Y) (A. 4) 

XPXD.3E.project(P) A start 1 '(E, P) A date.of(E, D) (A.5) 

It should be noted that the theory we have outlined here is not the most 
popular one in theoretical linguistic circles. Currently, the "standard" ap- 
proach is that described in (Kartunnen 1977), which makes the denotation 
of a question the set of true answers. We feel that there are good reasons 
to query the appropriateness of this idea, but a discussion of the issues lies 
too far outside the scope of the thesis; the interested reader is referred to 
(Rayner and Janson 1987) for our objections to Kartunnen's approach. 
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Appendix B 

Syntax and semantics of TRL 



This appendix briefly defines the syntax and semantics of the TRL language. 
TRL is a conservatively extended first-order logic, which is used as the level 
of representation in CLARE that supports inference operations. When dis- 
cussing AET at an abstract level, we consequently often find it convenient 
to use normal logical notation. We indicate for each construct the "normal" 
logical equivalent. 

There are three basic types of construct: terms, abstracts and forms. We 
list each one seperately. 

NB: The version of TRL described here is that used in the body of the 
thesis, and represents a slightly rationalized form of the implemented version. 
The most important differences concern the concrete syntax for typed terms 
(here, Type#Id), and higher-order constructs for counting, summing and 
ordering. 

B.l Terms 

A TRL term can be any of the following: 

1. A variable, represented as a Prolog variable. 

2. A constant, represented as a Prolog atom. 

3. The result of applying a function symbol to a list of terms, represented 
as a complex Prolog term. 

When using standard logical notation, we do not enforce any syntactic con- 
vention to distinguish between variables and constants, relying on this being 
clear from context. 
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We will distinguish terms of the Type#Id, where Type is a TRL constant 
and Id is a TRL term. These will have the conventional meaning "the object 
of type Type, whose database identifier is Id". In normal logical syntax we 
will write these as Type : Id. 

B.2 Abstracts 

If P is a TRL form or a TRL abstract, and XI... Xn are TRL variables, then 
X1"X2. . .Xn'P 

is a TRL abstract. It denotes a n-ary relation R between objects, such that 
R holds between the objects denoted by Al... An iff the formula resulting 
from substituting Ai for Xi in P holds. In normal logical notation, we write 
A X\ . . . \X n . P. 

B.3 Forms 

A TRL form can be any of the following: 
Conjunction If P and Q are TRL forms, then 
and(P,Q) 

is a TRL form, which holds iff both P and Q hold. Conjunctions are as 
usual written P A Q in normal logical notation. 

Disjunction If P and Q are TRL forms, then 

or(P,Q) 

is a TRL form, which holds iff either P or Q holds. Disjunctions are as 
usual written P V Q in normal logical notation. 

Negation If P is a TRL form, then 

not(P) 

is a TRL form, which holds iff P does not hold. Negations are written 
—>P in normal logical notation. 

Implication If P and Q are TRL forms, then 



B.3. FORMS 
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impl(P,Q) 
Q <- P 

are alternate ways of writing the same TRL form, which holds iff either 
Q holds or P does not hold. In normal notation, we will permit both 
P -> Q and Q <- P. 

Equivalence If P and Q are TRL forms, then 

P <-> q 

is a TRL form, which holds iff P and Q either both hold or both fail to 
hold. In normal notation, we write P = Q. 

Existential quantification If P is a TRL form, and [XI, X2, . . .] is a 

list of TRL variables, then 

exists ([XI, X2, . . .] ,P) 

is a TRL form, which holds iff P hold for some instantiation of the 
variables [XI, X2, . . .] . In normal notation, we write 3X\,X2, ....P. 

Universal quantification If P is a TRL form, and [XI, X2, . . .] is a list 
of TRL variables, then 

forall([Xl, X2, . . .] ,P) 

is a TRL form, which holds iff P hold for all instantiations of the 
variables [XI , X2 ,...]. In normal notation, we write VXl, X2, ....P. 

Counting If X~P is a TRL abstract, and N is a TRL term, then 

cardinality (N,X~P) 

is a TRL form, which holds iff there are precisely N instantiations of X 
such that P holds. In normal notation, we write count (N, XX. P). 

Summing If X~P is a TRL abstract, and N is a TRL term, then 

sum(Sum,X~P) 

is a TRL form, which holds iff 
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1. all objects A such P holds when A is substituted for X are summable 
quantities 

2. Sum is their sum. 

In normal notation, we write sum(Sum, XX. P). 

Ordering If X~D~P is a TRL abstract, and N and Ordering are TRL terms, 
then 

order (Select ed,X~D~P , Ordering) 
is a TRL form, which holds iff 

1. Ordering is a term representing an ordering relation 

2. DMax is the maximal Dl under the relation represented by Ordering 
such that P when Dl is substituted for D and some XI is substi- 
tuted for X, and 

3. Selected is such an XI 

In normal notation, we write order (Selected, XXXD.P(X, D), Ordering). 
Meta-knowledge If P is a TRL form, then 
kw(P) 

(read "knows-whether" P) is a TRL form, which holds iff there is an 
effective translation of P (cf. Section 2.4.2| ). In normal notation we 
write kw(P). 

Necessity If P is a TRL form, then 

def (P) 

(read "P is true by definition") is a TRL form, which holds iff P is 
implied by the background theory without the database. 



Appendix C 

Translating to SQL 



This section briefly describes the module responsible for synthesis of actual 
SQL queries. The conversion module takes as input a TRL form P, assumed 
to represent a question; it outputs a form P' , such that P and P' are equiv- 
alent and as much as possible of P has been replaced by calls to the SQL 
interface. The interface is mediated through the predicate 

sql_select (Vars , SQLQuery) 

where SQLQuery is a term representing an SQL SELECT statement, and Vars 
is a list whose length is equal to the number of selected variables in SQLQuery. 
The intended semantics are that 

sql_select (Vars , SQLQuery) 

holds iff Vars are a row selected by SQLQuery. SQLQuery is a logical term 
representing the abstract SQL syntax; conversion to concrete SQL syntax 
is handled by the low-level SQL interface, and is straightforward. We now 
describe how the conversion process is carried out; we will illustrate by con- 



tinuing the extended example from section 4.9. We use the same abbreviated 
notation, shortening exists to E and forall to A. Recall that the original 
query was 

(SI) Show all payments made to BT during 1990. 

This receives the final translated TRL representation (slightly simplified in 
the interests of readability), 

A( [TransId,Date,DBDate,AmtNum] , 

impl (and (TRANS (Trans Id , DBDate ,bt , AmtNum) 
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and(sql_date_convert (Date ,DBDate) , 

and (t_precedes (date ([1990, 1,1]) .Date) , 

t_precedes (Date , date ( [1990 ,12,31]))))) 
execute_in_f uture (display( [TransId,DBDate ,bt , AmtNum] ) ) ) ) 

which can be glossed as 

"Find all TRANS tuples with trn_id field Transld, cheque_date 
field DBDate, payee field bt and amount field AmtNum, such that 
DBDate represents a date after 1/1/90 and before 31/12/90; and 
for each one display the list [Transld, DBDate , bt , AmtNum] ." 

Taking the conclusion first, the translation to SQL form produced is 

A ( [Transld, DBDate, AmtNum] , 

impl(sql_select( [Transld, DBDate, AmtNum] , 

SELECT ( [t_l.trn_id,t_l. amount, t_l.cheque_date] , 
FR0M( [alias (TRANS, t_l)]) , 
WHERE ( [t_l.payee=bt, 

sql_date_=< ( 1- JAN-90 , 

t_l . cheque_date) ) , 
sql_date_=< (t_l . cheque_date , 
31-DEC-90))])) , 
execute_in_f uture (display( [Transld, DBDate ,bt , AmtNum] ) ) ) 

Here, the abstract SQL syntax is a hopefully transparent representation of 
the SQL query whose concrete syntax will be 

"SELECT DISTINCT t_l.trn_id , t_l . cheque_date , t_l. amount 
FROM TRANS t_l 
WHERE t_l. payee = 'bt' 
AND '1- JAN-90' <= t_l . cheque_date 
AND t_l.cheque_date <= '31-DEC-90" 

We now explain in more detail how this result can be produced. Pro- 
cessing traces the following series of top-level steps: 

1. Translate representation- independent evaluable predicates such as t_- 
precedes into database access language dependent primitives using 
AET. 

2. Insert database column names into database predicates. 
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3. Make column names unique by associating a "relation alias" with each 
occurrence of a database predicate. 

4. Group together conjunctions of goals suitable for turning into SELECT 
statements. Goals suitable for inclusion are goals representing database 
lookups and goals that map onto conditions in WHEN clauses. For each 
such conjunction, do the following: 

(a) Extract the variables that are to be selected. 

(b) Replace variables by column descriptions. 

(c) Extract the variables that are constrained to have fixed values, 
and add these as suitable equalities to the WHEN clause. 

(d) If more than one relation instance is referenced, add equalities to 
the WHEN clause to represent the join. 

5. Simplify the result. 

We use the example to illustrate. The first step is to use AET to translate 
the occurrences of t_precedes. The relevant equivalence is 

t_precedes (Datel ,Date2) <-> 
exists ( [DBDatel,DBDate2] , 

and(sql_date_convert (Datel ,DBDatel) , 

and(sql_date_convert (Date2 ,DBDate2) , 
sql_date_=< (DBDatel ,DBDate2) ) ) ) 

applied twice; after some simplification (exploiting the fact that db_date_- 
convert is a function from each of its arguments to the other one, see sec- 
tion 3.6.2), the result is 



A ( [Transld , Date , DBDate , AmtNum] , 

impl (and (TRANS (Transld , DBDate , bt , AmtNum) 
and(sql_date_convert (Date , DBDate) , 
and (sql_date_=< ( 1- JAN-90 , DBDate) 

sql_date_=< (DBDate , 31-DEO90) ) ) ) ) , 
execute_in_f uture (display( [Transld, DBDate ,bt , AmtNum] ) ) ) 

Note that l-JAN-90 and 31-DEC-90 are atomic SQL date representations. 
The next two steps are fairly trivial in nature, and involve substituting SQL 
column names in the TRANS relation and creating a unique relation alias 
t_l for it. (Since there is only one relation here, this step is not actually 
necessary, but we show it for completeness). The result is 
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A( [TransId,Date,DBDate,AmtNum] , 

impl (and(tuple (t_l , TRANS ( [trn_id=TransId , 

cheque_date=DBDate , 
payee=bt , 
amount=AmtNum] ) ) , 
and(sql_date_convert (Date ,DBDate) , 
and(sql_date_=<(l-JAN-90,DBDate) 

sql_date_=< (DBDate , 31-DEO90) ) ) ) ) , 
execute_in_f uture (display( [Transld, DBDate ,bt , AmtNum] ) ) ) 

Conjunctions are now when possible turned into sql_select goals; the only 
suitable conjunction is 

and(tuple(t_l, TRANS ( [t r n_ i d=Tr ans I d , 

cheque_date=DBDate , 
payee=bt , 
amount=AmtNum] ) ) , 
and(sql_date_=<(l-JAN-90, DBDate) 

sql_date_=< (DBDate , 31-DEC-90) ) ) 

Here, the database look-up goals are the singleton 

{tuple (t_l, TRANS ( [trn_id=TransId, 

cheque_date=DBDate , 

payee=bt , 

amount = AmtNum] ) ) } 

and the initial WHEN clause goals are 

{sql_date_=<(l-JAN-90, DBDate) 
sql_date_=< (DBDate , 31-DEO90) ) } 

Consulting the database look-up goals, the variables to be selected are 
Transld, DBDate and AmtNum, so they end up being the list of variables 
in the sql_select goal's first argument; then replacing the variables inside 
the SELECT with column descriptions, we replace Transld with t_l .trn_id, 
DBDate with t_l . cheque_date and AmtNum with t_l . amount. The WHEN 
clause goals now become 

{sql_date_=<(l-JAN-90,t_l . cheque_date) 
sql_date_=< (t_l . cheque_date , 31-DEC-90) ) > 
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There is a single column, payee, constrained to have a fixed value, bt, so it 
adds another goal 

t_l .payee=bt 

to the WHEN clause. The final result is the sql_select goal 

sql_select ( [Transld , DBDate , AmtNum] , 

SELECT ( [t_l .trn_id,t_l . amount ,t_l . cheque_date] , 
FR0M( [alias (TRANS, t_l)] ) , 
WHERE ( [t_l.payee=bt, 

sql_date_=< ( 1- JAN-90 , 

t_l . cheque_date) ) , 
sql_date_=< (t_l . cheque_date , 
31-DEC-90))]))))) 

Replacing the conjunction with the sql_select goal, we reach the final form, 

A ( [Transld, DBDate, AmtNum] , 

impl(sql_select( [Transld, DBDate, AmtNum] , 

SELECT ( [t_l . trn_id, t_l . amount ,t_l . cheque_date] , 
FROM ( [al i as ( TRANS , t _ 1 ) ] ) , 
WHERE ( [t_l.payee=bt, 

sql_date_=< ( 1- JAN-90 , 

t_l . cheque_date) ) , 
sql_date_=< (t_l . cheque_date , 
31-DEC-90))]))) , 
execute_in_f uture (display( [Transld, DBDate ,bt , AmtNum] ) ) ) 



